BE recordings one hour late

[monochromec@…]

Just noticed that the BE starts recording programmes one hour late. Checked the following:

• date / TZ OK as reported by the underlying OS (stock Ubuntu 12.10)
• record table in mythconverg has the proper time in starttime / endtime columns
• BE status in mythweb shows one hour offset
• Upcoming recordings in mythweb show proper (ie. initially programmed) schedule as well

Let me know if you need more information. BTW: Tested this on a 0.26.0 branch but also applies to 0.27 (git clone of current repo contents)

[gigem]

Is this still a problem? If so, please provide detailed logs, screen shots, etc. of the things you checked and how you checked them. Also, what is the contents of your /etc/timezone and /etc/localtime files?

[monochromec@…]

Exact log files are no longer available due to the delay of creating the comment but did not contain any further useful information apart from state changes (which reflect the software defect) at the beginning of the incorrect recording. All other relevant information is in the original ticket.

/etc/timezone contains "Europe/Berlin?". As /etc/locatime is a binary file (and this ticketing system apparently doesn't allow attaching files to comments) and zdump output is rather lenghty, please let me know how I should transfer this information.

[stuartm]

When you say that the record table shows the 'correct' times. Are those the correct times as localtime, or GMT? They should be GMT or local time minus one hour.

Does your program table have times in GMT or GMT+1 (local time?).

[monochromec@…]

The record table shows the correct local time (CEST) and so does the program table.

[gigem]

All times in record, except for the "find" variations, should be in UTC not local time. Does the following MySQL command give the correct local, UTC, and local times?

select now(), utc_timestamp(), convert_tz(utc_timestamp(), 'UTC', 'SYSTEM');

If either of the first two are wrong, you system timezeon is not set properly. If the last on is wrong, your MySQL zone info is not correct.

[stuartm]

Are you using XMLTV (mythfilldatabase), and if so which grabber, is it configured to run automatically or have you set it up to run with special arguments or using a file input?

[monochromec@…]

Replying to gigem:

All times in record, except for the "find" variations, should be in UTC not local time. Does the following MySQL command give the correct local, UTC, and local times?

select now(), utc_timestamp(), convert_tz(utc_timestamp(), 'UTC', 'SYSTEM');

If either of the first two are wrong, you system timezeon is not set properly. If the last on is wrong, your MySQL zone info is not correct.

Interesting observation as the BE used to work before with all times in the local TZ (find columns in DB table empty). Consequently, the SQL statement displays the correct values for all three columns of the returned row.

[stuartm]

Previous versions of MythTV stored program guide data using local time, 0.26 stores everything in UTC/GMT to improve portability and resolve issues around daylight savings changes.

[gigem]

Sadly, to fix a minor bug that occurs twice a year when the time changes, we had to greatly complicate our time handling.

Anyway, since the test times are correct, the problem probably lies (as stuartm indicated) with xmltv and/or how you're using it. What grabber and options are you using?

[monochromec@…]

Unfortunately, the issue is not related to DST changes whatsoever but rather to the way Mythweb interacts with the DB / BE if MythWeb doesn't cater for UTC changes but continues to use the previous time settings. So the test times are not correct in contrast to your assumptions.

And I'm not using xmltv or some grabber. For some reason, the reply to stuartm's message never made it into the history of this ticket.

[dekarl@…]

What did you do? What has happened? What did you expect to happen?

It sounds like you scheduled a recording via Mythweb (How exactly?) that got recorded at a different time then you expected. Is that correct?

Everything else is working properly? The guide is at the right time in Mythweb and Mythfrontend? Recordings scheduled via Mythfrontend work as expected? (in Mythweb and Mythfrontend)

PS: Can you verfy that Mythweb and the rest of MythTV have matching versions? There have been issues in the past where only some packages got updated.

[sphery]

And note that the PHP bindings used by MythWeb may be the wrong version even if MythWeb is the right version (and the PHP bindings are often separately packaged), so please check them, also.

[monochromec@…]

What did I do:

• Scheduled a recording via Mythweb and times checked out in the DB and mythweb but BE was one hour late (see initial ticket comments).

Mythweb version annd BE version match. I take it the php bindings came with the Mythweb package?

[Karl Egly]

On Ubuntu you have:
php-mythtv with the bindings and
mythweb with mythweb

Was it a normal recording rule (click on a program in the guide and select record) or did you create a manual recording rule (select manual and write in the time by hand)?

[monochromec@…]

I used mythweb straight from the repo when creating a manual schedule. The php code did require patching as outlined in ticket #10504 though.

[stuartm]

As previously stated, if the times in the record and program table are CEST, then they are wrong. If you are not using xmltv, then where does your guide data come from? EIT? Are you using DVB-C, DVB-T or DVB-S? Please give as much detail as you can.

[paulh]

No reply in 15 months. This is an old ticket and if it was a real problem we would have heard of more cases by now. Also MythWeb is becoming obsolete so is no longer supported.