Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#10048 closed Bug Report - General (Invalid)

failure to restart recording after crash for certain recordingtypes

Reported by: xunspam-sususu@… 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

Attachments (0)

Change History (4)

comment:1 Changed 3 years ago by gigem

  • Resolution set to Invalid
  • Status changed from new to closed

The observed behavior is intended. Later recordings are always preferred over interrupted recordings when the rule type allows them.

comment:2 Changed 3 years ago by xunspam-sususu@…

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 3 years ago by gigem

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 3 years ago by gigem

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.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.