Mailing List Archive: MythTV: Users

Myth 0.21 expiring ALL shows too soon with TONS of disk space available

Index | Next | Previous | View Threaded

mcdonald.ryan at gmail

May 2, 2012, 10:34 AM

Post #1 of 22 (1062 views)
Permalink

Myth 0.21 expiring ALL shows too soon with TONS of disk space available

I have a myth 0.21 system that has been working perfectly for quite a
while. I recently lost the 4TB internal array I was running due to a drive
failure. I replaced it with a 5.5TB internal array. I did this simply by:

* shutting down
* installing new replacement disks
* creating the array
* recreating the exact same storage paths
* purged all shows from the DB using mysql command line.
* restarted myth backend

The system works perfectly but it is acting like "Extra Disk Space" is
defined as 4TB (when its actually defined as 6GB). All storage groups
point to the same partition. Myth is expiring shows everyday and the free
space for the single storage partation stays right at 4TB available. The
recording schedules do NOT have any expiration overrides.

Ideas?

Log shows:

# cat mythbackend.log |grep xpir
2012-05-02 12:00:10.799 AutoExpire: CalcParams(): Max required Free Space:
6.0 GB w/freq: 6 min
2012-05-02 12:00:10.898 Expiring 2299 MBytes for 2009 @ Thu Apr 12 17:00:00
2012 => FOX 26 News at 5PM
2012-05-02 12:06:10.913 AutoExpire: CalcParams(): Max required Free Space:
6.0 GB w/freq: 15 min
2012-05-02 12:21:11.015 AutoExpire: CalcParams(): Max required Free Space:
6.0 GB w/freq: 15 min
2012-05-02 12:21:11.138 Expiring 1186 MBytes for 2012 @ Thu Apr 12 17:30:00
2012 => NBC Nightly News

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sde1 9.2G 4.4G 4.4G 50% /
udev 10M 260K 9.8M 3% /dev
/dev/sde3 222G 1.2G 221G 1% /tempdisk
none 991M 0 991M 0% /dev/shm
192.168.200.4:/ifs 5.3T 4.2T 1.2T 79% /mnt/private
/dev/md0 5.5T 1.5T 4.1T 27% /data

gjhurlbu at gmail

May 2, 2012, 11:28 AM

Post #2 of 22 (1046 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On Wed, May 2, 2012 at 10:34 AM, Ryan McDonald <mcdonald.ryan [at] gmail> wrote:
> I have a myth 0.21 system that has been working perfectly for quite a while.
> 狢 recently lost the 4TB internal array I was running due to a drive
> failure. 狢 replaced it with a 5.5TB internal array. 狢 did this simply by:

Seriously? 0.21 is about 4 years old. I'm sure this bug has been
fixed since. It is quite likely a case of 32bit vs 64bit on the disk
free. I seem to recall having fixed this in the last year or two.

Unless you have a burning desire to stay with 0.21, I would strongly
suggest upgrading to something newer.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mcdonald.ryan at gmail

May 2, 2012, 11:39 AM

Post #3 of 22 (1052 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

>It is quite likely a case of 32bit vs 64bit

Might be true. 4T can be expressed as a 32-bit number whereas 5.5T
can't. Is there a change-log or bug-report anywhere that shows a 32/64
problem has been fixed with the file system? (The normal change-logs
don't mention it). Upgrading is be a *HUGE* pain in this case. I'd like
to confirm an upgrade is known to fix this problem before upgrading.
This system is used in the enterprise by about 180 people (literally)
with a custom front end. Downtime (or possible loss of media) is not
practical.

-Ryan

On 05/02/12 13:28, Gavin Hurlbut wrote:
> On Wed, May 2, 2012 at 10:34 AM, Ryan McDonald<mcdonald.ryan [at] gmail> wrote:
>> I have a myth 0.21 system that has been working perfectly for quite a while.
>> I recently lost the 4TB internal array I was running due to a drive
>> failure. I replaced it with a 5.5TB internal array. I did this simply by:
>
> Seriously? 0.21 is about 4 years old. I'm sure this bug has been
> fixed since. It is quite likely a case of 32bit vs 64bit on the disk
> free. I seem to recall having fixed this in the last year or two.
>
> Unless you have a burning desire to stay with 0.21, I would strongly
> suggest upgrading to something newer.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 2, 2012, 11:45 AM

Post #4 of 22 (1053 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 02:39 PM, Ryan McDonald wrote:
>
>> It is quite likely a case of 32bit vs 64bit
>
> Might be true. 4T can be expressed as a 32-bit number whereas 5.5T
> can't. Is there a change-log or bug-report anywhere that shows a
> 32/64 problem has been fixed with the file system? (The normal
> change-logs don't mention it). Upgrading is be a *HUGE* pain in this
> case. I'd like to confirm an upgrade is known to fix this problem
> before upgrading. This system is used in the enterprise by about 180
> people (literally) with a custom front end. Downtime (or possible
> loss of media) is not practical.

Yes, there were some issues fixed by Raymond Wagner before 0.25 release
that were caused by extremely-large single-filesystem sizes.

Upgrade to 0.25. Note that you can't do that in a single step--0.25
can't upgrade a 0.21-fixes database schema--so you'll have to go through
an intermediate version, such as installing current 0.24-fixes, running
mythtv-setup (and, perhaps mythfrontend) to upgrade your DB schema, then
installing current 0.25-fixes and running mythtv-setup to upgrade to
0.25 schema version.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 2, 2012, 11:48 AM

Post #5 of 22 (1053 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 02:45 PM, Michael T. Dean wrote:
> On 05/02/2012 02:39 PM, Ryan McDonald wrote:
>>
>>> It is quite likely a case of 32bit vs 64bit
>>
>> Might be true. 4T can be expressed as a 32-bit number whereas 5.5T
>> can't. Is there a change-log or bug-report anywhere that shows a
>> 32/64 problem has been fixed with the file system? (The normal
>> change-logs don't mention it). Upgrading is be a *HUGE* pain in this
>> case. I'd like to confirm an upgrade is known to fix this problem
>> before upgrading. This system is used in the enterprise by about 180
>> people (literally) with a custom front end. Downtime (or possible
>> loss of media) is not practical.
>
> Yes, there were some issues fixed by Raymond Wagner before 0.25
> release that were caused by extremely-large single-filesystem sizes.
>
> Upgrade to 0.25. Note that you can't do that in a single step--0.25
> can't upgrade a 0.21-fixes database schema--so you'll have to go
> through an intermediate version, such as installing current
> 0.24-fixes, running mythtv-setup (and, perhaps mythfrontend) to
> upgrade your DB schema, then installing current 0.25-fixes and running
> mythtv-setup to upgrade to 0.25 schema version.

Oh, and here's your confirmation:

http://www.gossamer-threads.com/lists/mythtv/users/499679#499679

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

raymond at wagnerrp

May 2, 2012, 11:56 AM

Post #6 of 22 (1053 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 5/2/2012 14:39, Ryan McDonald wrote:
> Is there a change-log or bug-report anywhere that shows a 32/64
> problem has been fixed with the file system?

http://code.mythtv.org/trac/changeset/83a03aaae367/mythtv

Note that as explained in the commit, the previous use of size_t means
this problem only exists on systems where the maximum array size is 4B,
which means those running 32-bit operating systems. The combination of
someone running a RAID array, or modern hard drives, with more than 2TB
of free space on a single filesystem, and still continuing to use
antiquated 32-bit versions of Linux, is sufficiently rare that no one
even noticed the problem until late last year.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mcdonald.ryan at gmail

May 2, 2012, 12:12 PM

Post #7 of 22 (1046 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

Thanks for the replies everyone. Two questions though.

1 - For 32-bit hosts, the fix first appears in 0.25? (or in some 0.24
patchlevelX 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 this 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 remaining at any one given time? Then, I'd slowly remove
these dummy files until they are all replaced by actual media. Would
this work?

Also.... If I'm sitting at 0.21 right now, which versions do I need to
install BEFORE I upgrade to 0.25 to make sure all the schemas get updated?

-Ryan

On 05/02/12 13:56, Raymond Wagner wrote:
> On 5/2/2012 14:39, Ryan McDonald wrote:
>> Is there a change-log or bug-report anywhere that shows a 32/64
>> problem has been fixed with the file system?
>
> http://code.mythtv.org/trac/changeset/83a03aaae367/mythtv
>
> Note that as explained in the commit, the previous use of size_t means
> this problem only exists on systems where the maximum array size is
> 4B, which means those running 32-bit operating systems. The
> combination of someone running a RAID array, or modern hard drives,
> with more than 2TB of free space on a single filesystem, and still
> continuing to use antiquated 32-bit versions of Linux, is sufficiently
> rare that no one even noticed the problem until late last year.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 2, 2012, 12:44 PM

Post #8 of 22 (1030 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 03:12 PM, Ryan McDonald wrote:
> Thanks for the replies everyone. Two questions though.
>
> 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
that, 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 this 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 remaining at any one given time? Then,
> I'd slowly remove these dummy files until they 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 install 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
to 0.25-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 upgrading 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.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Larry.Finger at lwfinger

May 2, 2012, 12:51 PM

Post #9 of 22 (1033 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 02:44 PM, Michael T. Dean wrote:
> On 05/02/2012 03:12 PM, Ryan McDonald wrote:
>> Thanks for the replies everyone. Two questions though.
>>
>> 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 that,
> 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 this
>> 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 remaining
>> at any one given time? Then, I'd slowly remove these dummy files until they
>> 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 install
>> 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 to
> 0.25-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 upgrading
> 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 upgrade.

Larry

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 2, 2012, 1:21 PM

Post #10 of 22 (1032 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 03:51 PM, Larry Finger wrote:
> On 05/02/2012 02:44 PM, Michael T. Dean wrote:
>> On 05/02/2012 03:12 PM, Ryan McDonald wrote:
>>> Thanks for the replies everyone. Two questions though.
>>>
>>> 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
>> that,
>> 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 this
>>> 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
>>> remaining
>>> at any one given time? Then, I'd slowly remove these dummy files
>>> until they
>>> 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 install
>>> 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 to
>> 0.25-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
>> upgrading
>> 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 upgrade.

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).

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

joe at thefrys

May 2, 2012, 2:24 PM

Post #11 of 22 (1027 views)
Permalink

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
>>> that,
>>> 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
>>>> this
>>>> 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
>>>> remaining
>>>> at any one given time? Then, I'd slowly remove these dummy files until
>>>> they
>>>> 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
>>>> install
>>>> 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
>>> to
>>> 0.25-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
>>> upgrading
>>> 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
>> upgrade.
>>
>
> 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.

raymond at wagnerrp

May 2, 2012, 3:37 PM

Post #12 of 22 (1030 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 5/2/2012 17:24, Joseph Fry wrote:
> If you have the space, why not just partition your array?

Because the only good reason to partition something is because you're
going to run significantly different filesystems optimized for specific
tasks. Doing it for any other reason is something better performed by a
single filesystem and quotas. If he has a lot of custom development in
his frontend, he probably has sufficient understanding of programming to
figure out how to apply the two line patch in 10d562420 against 0.21,
and recompile.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

gary.buhrmaster at gmail

May 2, 2012, 4:36 PM

Post #13 of 22 (1018 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On Wed, May 2, 2012 at 10:37 PM, Raymond Wagner <raymond [at] wagnerrp> wrote:
....
> Because the only good reason to partition something is because you're going
> to run significantly different filesystems optimized for specific tasks.

Well, not always. In the "good ol' days", file systems
had limits that could be mitigated against by partitioning.
There was that old 32MB DOS limit. Various versions
of ufs performed quite poorly with some large directory
sizes (everything was a sequential search). Even today,
with ext3, a large multi-terabyte file system can take
many many hours to fsck depending on how the backend
disk array is configured.

So while your statement may be true for what are
considered more modern filesystems (gpfs, zfs,
btrfs, etc.), I will not concede it is a universal truth
(although I will concede that people should be running
modern file systems).

In any case, I do agree that applying the patch is
probably the preferred short term solution (followed
by a plan to upgrade to a "modern" version of
MythTV, which (presumably) means an upgrade
to the custom frontend. Bits rot, and even software
should have a life-cycle replacement/upgrade plan).

Gary
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

dfishburn.mythtv at gmail

May 2, 2012, 7:19 PM

Post #14 of 22 (1017 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

>> 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 upgrade.
>
> 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).
>
Hmmm,

collation_database: latin1_swedish_ci
character_set_database: latin1

I just did some Google searches on how to change the collation of a
mysql database.

http://en.gentoo-wiki.com/wiki/Convert_latin1_to_UTF-8_in_MySQL

It is somewhat involved and the above link provides 3 different approaches.

I was reading this thread:
http://www.gossamer-threads.com/lists/mythtv/users/362102

Which seems to imply the charset conversion will be automatic.

Assuming I run this before the upgrade, is there anything else I need to
worry about from a MythTV perspective?

Will anything break?
Or do I have to update any config files or settings to accommodate this
change?

Thanks,
Dave

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

May 2, 2012, 8:27 PM

Post #15 of 22 (1016 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/02/2012 10:19 PM, DFishburn wrote:
>>> 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 upgrade.
>>
>> 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).
>>
> Hmmm,
>
> collation_database: latin1_swedish_ci
> character_set_database: latin1

Yes, that's good. For a 0.21-fixes or below database, that's what you need.

>
> I just did some Google searches on how to change the collation of a
> mysql database.
>
> http://en.gentoo-wiki.com/wiki/Convert_latin1_to_UTF-8_in_MySQL
>
> It is somewhat involved and the above link provides 3 different
> approaches.

If you convert to UTF-8 (or if you had been running with a misconfigured
system where your MythTV database was using UTF-8), the upgrade would fail

> I was reading this thread:
> http://www.gossamer-threads.com/lists/mythtv/users/362102
>
> Which seems to imply the charset conversion will be automatic.

because it will attempt to do a conversion to UTF-8.

> Assuming I run this before the upgrade, is there anything else I need
> to worry about from a MythTV perspective?

Don't run anything--just let MythTV do the upgrade.

>
> Will anything break?
> Or do I have to update any config files or settings to accommodate
> this change?

Nope. Once you've upgraded to 0.22 or later schema, you should be good
with any server configuration.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

raymond at wagnerrp

May 2, 2012, 9:54 PM

Post #16 of 22 (1020 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 5/2/2012 19:36, Gary Buhrmaster wrote:
> On Wed, May 2, 2012 at 10:37 PM, Raymond Wagner<raymond [at] wagnerrp> wrote:
> ....
>> Because the only good reason to partition something is because you're going
>> to run significantly different filesystems optimized for specific tasks.
> Well, not always. In the "good ol' days", file systems
> had limits that could be mitigated against by partitioning.
> There was that old 32MB DOS limit. Various versions
> of ufs performed quite poorly with some large directory
> sizes (everything was a sequential search). Even today,
> with ext3, a large multi-terabyte file system can take
> many many hours to fsck depending on how the backend
> disk array is configured.

Just because something is necessary doesn't mean it's good. :)
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtvuser1818 at gmail

May 3, 2012, 5:44 PM

Post #17 of 22 (1002 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 2012-05-02, at 2:56 PM, Raymond Wagner <raymond [at] wagnerrp> wrote:

> On 5/2/2012 14:39, Ryan McDonald wrote:
>> Is there a change-log or bug-report anywhere that shows a 32/64 problem has been fixed with the file system?
>
> http://code.mythtv.org/trac/changeset/83a03aaae367/mythtv
>
> Note that as explained in the commit, the previous use of size_t means this problem only exists on systems where the maximum array size is 4B, which means those running 32-bit operating systems. The combination of someone running a RAID array, or modern hard drives, with more than 2TB of free space on a single filesystem, and still continuing to use antiquated 32-bit versions of Linux, is sufficiently rare that no one even noticed the problem until late last year.

I may be missing something, but wouldn't another solution be to upgrade to a 64-bit version of Linux on the backend(s)?

Roger
--
Sent from my iPod
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

jmorris at beau

May 3, 2012, 7:04 PM

Post #18 of 22 (1001 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On Thu, 2012-05-03 at 20:44 -0400, Roger Horner wrote:

> I may be missing something, but wouldn't another solution be to upgrade to a 64-bit version of Linux on the backend(s)?

Hmm, is there any major benefit to 64bit on a Myth system?

I originally installed Myth on an little 'ol beater slimline box I put
together in '03 that was PIII based so obviously it got a 32bit OS.
When I upgraded the hardware last year in preparation for going HD I
just moved the hard drive over and updated Debian to 6.0. Is there
enough benefit to justify a wipe and reload? The new hardware only has
2GB RAM so that isn't a limit.

Attachments:

signature.asc (0.19 KB)

mtdean at thirdcontact

May 3, 2012, 7:07 PM

Post #19 of 22 (1004 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/03/2012 10:04 PM, John Morris wrote:
> On Thu, 2012-05-03 at 20:44 -0400, Roger Horner wrote:
>
>> I may be missing something, but wouldn't another solution be to upgrade to a 64-bit version of Linux on the backend(s)?
> Hmm, is there any major benefit to 64bit on a Myth system?
>
> I originally installed Myth on an little 'ol beater slimline box I put
> together in '03 that was PIII based so obviously it got a 32bit OS.
> When I upgraded the hardware last year in preparation for going HD I
> just moved the hard drive over and updated Debian to 6.0. Is there
> enough benefit to justify a wipe and reload? The new hardware only has
> 2GB RAM so that isn't a limit.

That suggestion was specifically for the OP in this thread--as a
workaround for the bug that exists in 0.21 that's affecting him. So,
for him, the big benefit would be that it would prevent the bug he's
seeing from happening.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

jmorris at beau

May 4, 2012, 10:22 AM

Post #20 of 22 (990 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On Thu, 2012-05-03 at 22:07 -0400, Michael T. Dean wrote:

> That suggestion was specifically for the OP in this thread--as a
> workaround for the bug that exists in 0.21 that's affecting him. So,
> for him, the big benefit would be that it would prevent the bug he's
> seeing from happening.

Ok, just making sure. Couldn't really think of a reason it would make a
difference. And reinstalling to fix work around a minor bug sounded
like a pretty big hammer unless there were other benefits; in other
words unless the right attitude was that it was zany to still be running
32bit anyway so why not just take it as a sign to get with the program.

Attachments:

signature.asc (0.19 KB)

mtdean at thirdcontact

May 4, 2012, 11:55 AM

Post #21 of 22 (993 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On 05/04/2012 01:22 PM, John Morris wrote:
> On Thu, 2012-05-03 at 22:07 -0400, Michael T. Dean wrote:
>> That suggestion was specifically for the OP in this thread--as a
>> workaround for the bug that exists in 0.21 that's affecting him. So,
>> for him, the big benefit would be that it would prevent the bug he's
>> seeing from happening.
> Ok, just making sure. Couldn't really think of a reason it would make a
> difference. And reinstalling to fix work around a minor bug sounded
> like a pretty big hammer unless there were other benefits; in other
> words unless the right attitude was that it was zany to still be running
> 32bit anyway so why not just take it as a sign to get with the program.

I'd actually say it's zany to be running MythTV 0.21 before I would say
it's zany to be running 32-bit. :)

With MythTV 0.21, you're on your own--it's not going to get any bug
fixes and others won't be doing testing/debugging work on it. At least
32-bit GNU/Linux is still generally "supported"--or at least relatively
commonly used (even if not so much on x86).

So, IMHO, anyone using 0.21 or below should spend the time necessary to
fix the system so it can run modern MythTV--not doing so only means
doing so later. And the more time that passes between when "most
people" upgrade and when any given user does, the less people will
remember about upgrade issues and how to fix them--not to mention the
fact that our old database upgrade code is known to have issues with
modern Qt and MySQL due to changes to their upstream code and the way
current Qt/MySQL works in comparison to how they worked in the versions
where the code was written/maintained, which is a big part of the reason
that we dropped support for upgrading from 0.21 fixes or below database
schema versions in 0.25.

That said, I realize time and other constraints may be a factor in the
upgrade decision. However, I just wanted to make it clear--just like
GNU has said people shouldn't expect to be able to take random versions
of GNU applications and put them together to make a working
system--people shouldn't expect to be able to take a many, many years
old MythTV system and upgrade to current without problems (at least not
if expecting to keep their data). If nothing else (ignoring changes to
things like MySQL and Qt that can cause breakage or corruption of the
data), you're just stacking all of the issues you would have had for all
of the interim upgrades all together, making a much more complicated
mess to untangle.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtvuser1818 at gmail

May 4, 2012, 1:22 PM

Post #22 of 22 (985 views)
Permalink

Re: Myth 0.21 expiring ALL shows too soon with TONS of disk space available [In reply to]

On Thu, May 3, 2012 at 10:07 PM, Michael T. Dean
<mtdean [at] thirdcontact>wrote:

> On 05/03/2012 10:04 PM, John Morris wrote:
>
>> On Thu, 2012-05-03 at 20:44 -0400, Roger Horner wrote:
>>
>> I may be missing something, but wouldn't another solution be to upgrade
>>> to a 64-bit version of Linux on the backend(s)?
>>>
>> Hmm, is there any major benefit to 64bit on a Myth system?
>>
>> I originally installed Myth on an little 'ol beater slimline box I put
>> together in '03 that was PIII based so obviously it got a 32bit OS.
>> When I upgraded the hardware last year in preparation for going HD I
>> just moved the hard drive over and updated Debian to 6.0. Is there
>> enough benefit to justify a wipe and reload? The new hardware only has
>> 2GB RAM so that isn't a limit.
>>
>
> That suggestion was specifically for the OP in this thread--as a
> workaround for the bug that exists in 0.21 that's affecting him. So, for
> him, the big benefit would be that it would prevent the bug he's seeing
> from happening.

The othere advantage (which the OP wasn't suffering from) is the issue of
the 32-bit kernal not reserving enough of the Virtual Addressing Space for
device drivers (by default) when you have large amounts of RAM (typically
more than 768MB). This is common when combining certain capture cards
and the NVIDIA propriotary driver. This can be fixed by telling the kernal
to reserve more virtual memory (reducing the amount of RAM the kernel can
address directly), but the problem goes away completley with the 64-bit
kernal.

The way I see it, if you have a choice, use a 64-bit kernal, as there is
very rarely any harm in doing so. Is it worth the upgrade, probably not
unless it is the easiest solution to your problems.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads