mythrename.pl can't rename

[anonymous]

I believe this has to do with converting between Unix time. From one particular example, the script receives a starttime as 1178350606. This converts to '2007-05-06 00:36:46' in FROM_UNIXTIME(). The database record for that particular recording shows as '2007-05-05 00:34:00'. In my database query, the database is showing the date already formatted, not as a Unix-style timestamp. This is stated on the mysql website: Note: If you use UNIX_TIMESTAMP() and FROM_UNIXTIME() to convert between TIMESTAMP values and Unix timestamp values, the conversion is lossy because the mapping is not one-to-one in both directions. For details, see the description of the UNIX_TIMESTAMP() function. Could this be the issue?

[sphery <mtdean@…>]

Are these (serious) typos: '2007-05-06 00:36:46' in FROM_UNIXTIME() ... database record as '2007-05-05 00:34:00'?

They're nothing alike, there's no way you should get those particular (one-year-apart) values, let alone the 2min 46sec time difference. Is there a 46sec time difference (i.e. 00:36:46 and 00:36:00)? If there is, in fact, a 2:46 time difference, is the program start time 00:34:00 (progstart) and did your Myth box start recording (starttime) 2:46 late (i.e. are you looking at the wrong fields in the DB)?

[anonymous]

No typos, 2min 46sec apart. I don't see anything that looks one year apart. The error coming from mythrename.pl is:

Couldn't update basename in database for 1031_20070505003400.mpg: (UPDATE recorded SET basename=? WHERE chanid=? AND starttime=FROM_UNIXTIME(?))

So it is using the starttime field. If I modify the script to spit out the value it tries to pass into starttime, I get 1178350606 as the value, of which 'SELECT FROM_UNIXTIME(1178350606)' gives me '2007-05-05 00:36:46'

Now that you mention progstart, I checked that out, and this is what I get out of the database:

chanid starttime progstart

1031 2007-05-05 00:34:00 2007-05-05 00:36:46

So if I modify mythrename.pl to use progstart instead of starttime, all my files are renamed!

[anonymous]

Now I see the typo in the original ticket. Whoops. Attached a patch to fix this problem for me, although the script still uses $show->{'starttime'} as its value. I do not know which is the proper field to be used, or which is the proper object member to use.

[anonymous]

Second try, wasn't in mythtv root

[sphery <mtdean@…>]

The use of starttime is correct. The use of progstart is incorrect. There is only one progstart for each program (i.e. the scheduled program start time), but there could be 2 or 3 or 4 or ... starttime's for recordings of that same program if recording is interrupted (i.e. exiting LiveTV without hitting record then re-entering, changing channels in LiveTV, or due to backend shutdowns/crashes during recording). So the patch you've uploaded will actually corrupt databases in certain situations (I hope yours not included).

However, in the Perl bindings, what the DB calls starttime is called starttime (and the MythTV C++ code calls it startts). What the DB calls progstart, the Perl bindings and the MythTV C++ code calls recstartts. mythrename.pl should be using recstartts for finding recordings, not using starttime. So, mythtv-mythrename-use_recording_start_time.patch should fix the bug you found.

So, the question now is, was my use of "one-year-apart" (rather than "one-day-apart") a typo/read-o or an inside joke/challenge to try to convince you of the importance of verifying the data you're using to point out bugs because of the impossibility of properly diagnosing a bug with bad data. :)

[sphery <mtdean@…>]

The second paragraph of my previous comment is off, but the patch is correct (I got myself confused with all the names while typing the comment). What it should say is that we need to match the actual recording starttime (not the scheduled starttime for the program) in the DB to ensure we're updating the right record in the event of start early/end late or partial recordings.

[stuartm]

(In [13645]) Fixes mythrename. From looking at the changesets it has been broken since October last year when it was adapted to use the perl bindings. The bindings used the internal naming scheme for key variables, so starttime should be recstartts.

Problem spotted by Anon and patch by Sphery.

Closes #3426