Unscheduled recordings in MythTV 0.28 and MythTV 29

[JTLPA@…]

IS NOT present on fixes/0.27 (ad97d24), Debian 8.7

IS present on 0.28 xUbuntu 16.04, 0.28 from deb-multimedia on Debian 9, fixes/0.28 (v28.1-39-gfa485c62a) compiled from source on Debian 9.1 (what I am currently running) and 29 from source on Debian 9.

Note: fixes/0.27 will not compile on Debian 9.2, so I could not test it.

Happens on all of my computers

Happens on any one of my USB tuners Aver Media, On Air or SASEM, with one or all tuners connected.

The bug is unique to CH 18 which has 18-1, 18-2 and 18-3. If you schedule a recording on any one of CH 18's channels, the other two channels appear in “Program Guide” as scheduled recordings. If you delete either one of the unscheduled recordings, all recordings disappear from CH18. The unscheduled recording do not record, but prevent using both tuners in the card.

Attached a verbose log with notes at the top explaining timestamps events.

Have been fighting this for over a month now and hope you can shed some light on the bug.

If you need more information please tell me what to do and I will provide it to you.

Thank You

John

[JTLPA@…]

backend log

[Roger Siddons]

By "unscheduled recording" do you mean a scheduled recording that you did not schedule ?

Do they also appear on the "Upcoming Recordings" screen ? ie. Is it an issue with the Guide rather than the scheduler ? The log shows only 1 recording being scheduled.

Please confirm the program id & series id of all 3 programs are different. You can see them on the Program Info screen (I/Info/Menu->Program Info). If they have the same series id then a "Record All" rule should try and schedule them all. What type of rule are you using ?

prevent using both tuners in the card

Do you see a conflict if you try and schedule something else ?

A more useful log would be:

mythbackend -v scheduler --loglevel debug

as you reproduce the issue

[jtlpa@…]

mythbackend --loglevel debug -v schedule

[jtlpa@…]

By "unscheduled recording" do you mean a scheduled recording that you did not schedule ? YES

Do they also appear on the "Upcoming Recordings" screen ? NO. Only the program I scheduled to record shows up in "Upcoming Recordings".

Please confirm the program id & series id of all 3 programs are different. Pressing "I" in the guide for each channel only shows, Title, Description, MythTV status, no ID numbers, however, the two unscheduled recordings both show up as "MythTV will record". Did I do a wrong key press, as I don't see any id number or series?

Do you see a conflict if you try and schedule something else ? YES. Any recording scheduled for CH 18 always selects all channels on 18.

Attached the output of --loglevel debug -v schedule that you requested

[Bill Meek <keemllib@…>]

I'd leave 1118 set to WECP-DT and make 1182 WECP-SD or some other callsign. Same for 1183, e.g. make them unique.

[Roger Siddons]

Info Screen: You probably need to press I again to toggle the extra info.

As Bill says, the issue is likely that the 3 channels have identical callsigns. I couldn't find any decent documentation but this post ​https://lists.gt.net/mythtv/users/387300 expounds on why the guide thinks the 3 channels are linked.

Not sure about the conflict though.

Modify your callsigns via mythtv-setup/Channel Editor/E and try again.

[jtlpa@…]

Bill & rsiddons - THANKS SO MUCH TO BOTH OF YOU FOR HELPING ME OUT!

Bill your suggestion worked and CH18 now behaves as expected.

rsiddons thanks for the article, it was most enlightening, I will file it in the gray-matter and in my setup notes.

I do however, have one more question. Before changing call signs on 18-2 and 18-3, opened Channel Editor on fixes/0.27 (ad97d24)-Debian 8.7 and took a screen shot of 18-1, 18-2 and 18-3. Then switched to 0.28, compared them and they were identical.

So the question is, what changed in 0.28, were there changes to the way PSIS get handled or to the scheduler? The reason I ask is 0.27 still works fine.

Again a huge thank you for helping me out!

John

[Bill Meek]

#12612 touched the channel table, but I don't see how it would have caused this case. Unless the old DB is available, I'm closing this. Reopen if required.

Additional questions belong on the mailing list or forum.