[mythtv-users] Yet another silly action to drive the mythbox crazy

[Nicolas Krzywinski]

Haha, most of the answers where those I expected...

Just to clarify:
My system was not broken, this was only a temporary issue.
After freeing up some space, everything behaved correctly again.


Now, let me comment the answer topics:

- The "root reserved space" topic
Yes, root had extra space. No one told a different story. But mythfrontend/mythwelcome/mysql/mythweb did broke down nevertheless.

- The "don't place variable data on root" topic
Generally I agree. But doing so would decrease the efficiency of space usage. While this is an invalid argument on most systems of course, this should be weighted differently on a media system (for home usage).
Assembling low power consumption hardware with preferably low-to-no noise emission lead to e. g. a far more increased cost of disk space, because of strictly limiting storage alternatives to solid state disks. Things changed a bit meanwhile, but at the launch of my system (starting with a 64 gb ssd) I did not wanted to waste space for a separate system partition.
With the current 128 gb ssd the available space is far more relaxed, but at upgrading I only copied the system without altering the filesystem structure - for the next upgrade I will introduce partitioning ... for sure ;-) (a 250 gb ssd lays on my desk for a few weeks now, awaiting its htpc duty - but always either my myth machine or me are busy!! :D )

- The "there are so much side effects when implementing reserved space" topic
My guess is that there are different ideas of the dimensions for a reserved space. I understand all those doubts that rank around fast changing environmental conditions, taking into account the parallel activity of auto expire and so on.
But my idea of a reserved space, a recording should never fill up, is around some megabytes - maybe 20, 50, ... 80 ? Not more! This would allow any application to place their lock files, to write their textual moods to disk, to symlink this or that, .. basic stuff should work then.
Given the speed at which recordings consume e. g. 80 mb, this would change nearly nothing to letting the filesystem hard stop at zero free space.

- The "auto expire" topic
Yes, everything that was auto expirable, was deleted prior. First, I did thought that this failed - but after identifying the dimensions, it became clear, that simply the demand for space exceeded the possibilities.
One may ask why there is so much protected from auto expire? The reason for this is partially distributed amongst being to lazy to download unwatched recordings via webinterface to store it to my server and mythvidexport.pl failing in exporting many recordings due to unknown and charset problems.

- The "quota" topic
Ah, this is interesting! Never touched this. Will read into it. Plenty of thanks for this advise!


To sum up:
- I don't have a problem
- There was no pain to "recover" the system
- Therefore, I will do nothing to prevent this in future (except maybe applying a quota if this proves being of help)
- A htpc system is of no vital importance to a human (which is why I don't accept classic canonization for /)
- My story described an extreme situation where the system reached a kind of a natural end of its possibilities
- You have to do some hard things to bring the system into that situation
- No one was harmed

I ooooonly thought that there may be the chance of adding a more elegant behaviour to myth.

Wouldn't it be kind if myth would tell you s. th. like "Warning! There is no space left, stopping all recorder activites." instead of freezing your current view while letting start a battle for the last bytes in the background?

Just a proposal.


Keep up the good work!
Nicolas