Dvr/GetUpcomingList?Count=1 is reporting an old scheduled recording after a recording failure

[stephen@…]

MythTV Version : v0.28.1-38-geef6a48 MythTV Branch : fixes/0.28 Network Protocol : 88 Library API : 0.28.20161120-1 QT Version : 5.5.1 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr using_xv using_profiletype using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2

I had a recording failure for a recording using minisatip (IPTV) for Midsomer Murders. The recording never started due to a problem in minisatip. When I eventually noticed it, I manually stopped the recording. Then, when I called the Dvr/GetUpcomingList??Count=1 API, I was getting back a result saying that the Midsomer Murders recording scheduled for 2017-08-08T00:45:00Z is the next recording to happen (see GetUpcomingList?.xml file). That start time was in the past, but the end time for that failed recording (2017-08-08T02:25:00Z) was still in the future. I tried restarting mythbackend, but that did not change anything. I then waited until after that end time, and the API call then correctly returned the next scheduled recording.

[blm-ubunet@…]

For the last few years of master, the frontend has not indicated the correct status for failed recordings. The status is indicated correctly only after backend restart &/or the scheduled recording end time is past. This is a real pain for failed recordings because you can not "stop" the recording or re-start them from the frontend.

[J.Pilk@…]

In the past ISTR that a failed recording could be restarted if it was deleted from 'Previously recorded' - but now, on this box, that is only showing me programmes from more than two years ago; I still don't know why.

Copied from my post on the users list.

[Peter Bennett]

Replying to J.Pilk@…:

In the past ISTR that a failed recording could be restarted if it was deleted from 'Previously recorded' - but now, on this box, that is only showing me programmes from more than two years ago; I still don't know why.

Copied from my post on the users list.

I seem to remember that issue being reported before, and it was caused by a limit (I think 10,000) on a select, so that if you had more than 10,000 previously recorded shows the "previously recorded" list would be short. Unfortunately the ones that are dropped are not predictable. This should get a bug report of its own.

[stephen@…]

Replying to blm-ubunet@…:

For the last few years of master, the frontend has not indicated the correct status for failed recordings. The status is indicated correctly only after backend restart &/or the scheduled recording end time is past. This is a real pain for failed recordings because you can not "stop" the recording or re-start them from the frontend.

In my case, restarting mythbackend did not clear the problem, only waiting until after the end time worked.

However, on many failed recordings previously, I have been able to stop and restart them successfully after fixing a tuner problem. I have been doing that a lot recently as I have one USB tuner that has become unreliable but can easily be fixed by unplugging it and plugging it in again. If I stop the failing recording, fix the tuner, then restart the failing recording, it works fine in 0.28-fixes. If that does not work in v29, then I think I will not be upgrading for a while until I work out why my tuner is failing.

[Bill Meek]

The existing code includes recordings that pass this test:

GetRecordingEndTime() > MythDate::current()

     AsOf = 2017-08-08T02:06:30Z
StartTime = 2017-08-08T00:45:00Z
  StartTs = 2017-08-08T00:45:00Z
  EndTime = 2017-08-08T02:25:00Z
    EndTs = 2017-08-08T02:28:00Z
   Status = Failed

Status looks correct. I'll try to fail a recording myself and see what the backend is saying (30-Pre though.)

[stephen@…]

Here is the GetUpcomingList?.xml log file I have been unable to attach to the ticket. I have put it on my personal web server:

​http://www.jsw.gen.nz/mythtv/GetUpcomingList.xml

[J.Pilk@…]

Replying to pbennett:

I seem to remember that issue being reported before, and it was caused by a limit (I think 10,000) on a select, so that if you had more than 10,000 previously recorded shows the "previously recorded" list would be short. Unfortunately the ones that are dropped are not predictable. This should get a bug report of its own.

Thanks Peter. The limit is 20000 and I had ~45000 records. Ticket #13096

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues