joe at thefrys
May 2, 2012, 2:24 PM
Post #11 of 22
Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available
[In reply to]
>>>> 1 - For 32-bit hosts, the fix first appears in 0.25? (or in some 0.24
>>>> patchlevelX version)?
>>> The fix actually exists in 0.24-fixes. You could choose to upgrade to
>>> though there's probably not a lot of reason to use 0.24-fixes over
>>> 0.25-fixes--especially if anyone uses Live TV, you'll want 0.25-fixes.
>>> If you're
>>> upgrading, anyway, might as well go to current stable version.
>>> 2 - The way I understand the issue is that there is a problem
>>>> evaluating the
>>>> value that is returned by the "HowMuchSpaceIsLeft()" function. Assuming
>>>> is true, if I *had* to stay at 0.21, couldn't I just dd a bunch of 250MB
>>>> /dev/zero files into the file system so that the disk always has <1T
>>>> at any one given time? Then, I'd slowly remove these dummy files until
>>>> are all replaced by actual media. Would this work?
>>> Yes you could fill up some space to keep in the safe ranges. That would
>>> put you
>>> basically where you were before you lost the recordings.
>>>> Also.... If I'm sitting at 0.21 right now, which versions do I need to
>>>> BEFORE I upgrade to 0.25 to make sure all the schemas get updated?
>>> You could upgrade from 0.21 to 0.24-fixes, then upgrade from 0.24-fixes
>>> Basically, 0.25-fixes requires a database version from 0.22 or
>>> higher--it can't
>>> upgrade any older database versions. The main reason I'm recommending
>>> to 0.24-fixes (rather than an earlier version) is because it has some
>>> fixes for
>>> some random issues that can occur during database upgrade--especially
>>> with newer
>>> Qt and/or newer MySQL versions.
>> Ryan: Before you start the upgrade to 0.24, please be aware that there
>> are some circumstances where the upgrade from schema 1215 to 1216
>> apparently does nothing for nearly 8 hours before it finally finishes the
> If you use current 0.24-fixes to do the upgrade, you shouldn't have that
> problem (and, assuming your database schema/data isn't corrupt--i.e. due to
> invalid encoding, i.e. if you had been running a MySQL server set up with
> UTF-8 as the default character set--shouldn't have other problems).
If you have the space, why not just partition your array? Depending on the
filesystem you might even be able to shrink a partition without going
through a backup/restore.
Of course, I too recommend upgrading... but if you have a lot of
development into your custom frontend and whatnot, it may not be something
you can do in the short term... so shrink for short term then perform your
upgrade in a test environment until its ready for release.