Opened 13 years ago
Closed 13 years ago
Last modified 13 years ago
#10048 closed Bug Report - General (Invalid)
failure to restart recording after crash for certain recordingtypes
Reported by: | Owned by: | gigem | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | MythTV - Scheduling | Version: | 0.24-fixes |
Severity: | medium | Keywords: | recording recorder failure error scheduling rescheduling |
Cc: | Ticket locked: | no |
Description
I'm not certain if this is a bug or a feature, however its annoying.
current behaviour: After cancellation of recording e.g. by backend-crash, power failure, thunderstorm or whatever once the system is back online recording is not restarted. Sometimes the next reairing is scheduled if available.
I guess thats a bug, since when there is no find (singlerecord) recording restarts once backend is running again.
proposed behavior:
restart recording in any case, keeping the the previously scheduled order is better than rearranging everything even if there was another (low priority) recording to fill that spot. however adding the alternative airing to scheduling queue should be done additionally.
MythTV Version : v0.24.1-1-g347cd24 MythTV Branch : fixes/0.24 Network Protocol : 63 Library API : 0.24.20110505-1 QT Version : 4.6.2 Options compiled in:
linux debug using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg
Change History (4)
comment:1 Changed 13 years ago by
Resolution: | → Invalid |
---|---|
Status: | new → closed |
comment:2 Changed 13 years ago by
however this happens also when the next episode of the same show would be the later one ( so there is no later show, yet rerecording does not start)
please check the issued problem before invalidating the ticket
comment:3 Changed 13 years ago by
I did check the problem as reported, and as far as I can tell, the behaviour is still as intended. I have no idea what you're trying to say in comment:2. If you have specific information that you still think is a bug, and not just how you think it should work, please submit it. Otherwise, please take the discussion to the mailing lists.
comment:4 Changed 13 years ago by
It was pointed out to me on IRC what you might have been trying to say. With that in mind, I have a couple of things to add. First, if there is no later showing, aborted recordings should be restarted when the backend comes back up. If you have a case where this doesn't happen, please provide logs. Second, automatically marking restarted programs as allow-rerecord might be a good idea. That's a feature request, though, and we do not track those in this bug reporting system.
The observed behavior is intended. Later recordings are always preferred over interrupted recordings when the rule type allows them.