Opened 11 years ago

Closed 6 years ago

Last modified 4 years ago

#8052 closed Bug Report - General (Fixed)

MythWeb - Recording Forever - Upcoming Recordings Page

Reported by: Mark Garland <mythtvtrac@…> Owned by: Rob Smith
Priority: minor Milestone: unknown
Component: Plugin - MythWeb Version: 0.22
Severity: low Keywords: Upcoming Recordings, Recording Forever
Cc: Ticket locked: no


Please refer to

Original post below, though now a few people have responded saying that they experience it too.

I'm running 0.22.0+fixes22594-0ubuntu1 from the Ubuntu repositories. I have 3 DVB Freeview tuner cards in the UK, and they often record simultaneously without issues.

As it stands right now, I have "The Politics Show" which was set to record at midday last Sunday. If honest, I doubt too many things would have also been recorded from that time (perhaps a little LiveTV). MythWeb's Upcoming Recordings page still has the programme as "Currently Recording". The "Backend Status" page of MythWeb tells me that the tuner is idle.

On the Frontend, "Upcoming Recordings (Scheduled Recordings)" makes no mention of this recording. If I go into the "Watch Recordings" screen, the programme appears fully recorded (i.e. not appearing a different colour like in-progress recordings do) and I can watch the whole programme so I know that it finished recording at the right time. System Status also agrees with MythWeb that the tuner is idle.

The same tuner has since been used to record other programmes so I know that the tuner isn't "stuck" and can be reused by Myth.

So, in short, the only place that this programme erroneously looks like it is still recording is in MythWeb's "Upcoming Recording" page. If I edit the programme through MythWeb to say "Don't Record" or back to "Record anytime on channel BBC1", MythWeb crashes with Fatal error: Call to undefined method stdClass::save() in /usr/share/mythtv/mythweb/modules/tv/detail.php on line 241

Having seen this before, I'm pretty sure that a backend restart will simply make this vanish.

If you need anything further let me know. I'll make sure I'll only restart the backend if necessary so that I'll be in a position to try anything as requested.

Attachments (1)

mythbackend_log.txt (67.7 KB) - added by jgarrard_myth@… 7 years ago.
backend log of "Coronation Street" forever recording

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 years ago by Rob Smith

Status: newinfoneeded_new

Should be fixed now with the rewrite, can you confirm/deny?

comment:2 Changed 10 years ago by robertm

Resolution: fixed
Status: infoneeded_newclosed

No response, likely fixed.

comment:3 in reply to:  2 Changed 10 years ago by mythtvtrac@…

Replying to robertm:

No response, likely fixed.


I'm afraid that I'm only running MythTV on my main media centre, and being a 'production' machine it is only upgraded infrequently. I'll happily confirm whether this is fixed or not when I next upgrade, but this is likely not to be for another 6mths at least.



Changed 7 years ago by jgarrard_myth@…

Attachment: mythbackend_log.txt added

backend log of "Coronation Street" forever recording

comment:4 Changed 7 years ago by jgarrard_myth@…

I am still seeing this issue. I have uploaded a backend log of a recording of "Coronation Street" that is still showing as "Currently Recording" in MythWeb's upcoming recordings. The recording appears successful as the filesize is 650Mb, a thumbnail has been generated, and metadata lookup has occurred.

I am running three DVB-T2 tuners with NO multi-rec enabled. Two were recording, one was being used for live TV. I was not the user but they were also complaining about slow channel changes at the time.

MythTV Version : v0.26.0-116-gde5dd3b

MythTV Branch : fixes/0.26

Network Protocol : 75

Library API : 0.26.20130225-1

QT Version : 4.8.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_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2

comment:5 Changed 7 years ago by jgarrard_myth@…

Resolution: fixed
Status: closednew

comment:6 Changed 7 years ago by stuartm

Type: defectBug Report - General

comment:7 Changed 7 years ago by Karl Newman <SiliconFiend@…>

It seems that #11543 is a duplicate of this issue. I thought it started in 0.25, but it appears it's older than that. The trigger appears to be watching a scheduled recording while in Live TV (in other words, watching Live TV while using an input which has a recording scheduled at that time and proceeding to watch while it records). May be related to #11119, which has different symptoms but the same trigger.

comment:8 Changed 7 years ago by jtbreitner.lists@…

This is related to #11119, and the code change resolves it.

comment:9 Changed 6 years ago by Rob Smith

Resolution: Fixed
Status: newclosed

comment:10 Changed 4 years ago by mp23651@…

I still experiencing this problem, I'm running version 2:0.27.6+fixes.20160. I have an HDhomerun dual tuner and the other day, the backend reported that both tuners were recording a 12:00pm show @ 5:00pm. The status page showed both tuners were idle. In the mean time from 1:00 -5:00 the backend did not record the scheduled shows that it was supposed to record.

A simple restart of the backend process fixed the issue.

Note: See TracTickets for help on using tickets.