Bug #1788
Recordings not ending (3.4.27) - very large .ts files
0%
Description
In the last couple of weeks (ie since upgrading to 3.4.27) I have been having a random issue with recordings not ending. They just keep going and record everything on the channel until a restart the TVHeadend service. Not only does this create very large files 40GB+, but also causes me to miss recording as the tuner is tied up.
I am using a DiBcom 3000MC/P adapter. I have configured the EPG Grabber to fetch every 10 minutes (to detect schedule changes due to programme overruns), could this be confusing the DVR if the end time changes?
My system is lubuntu 13.4 (raring). I can see nothing unusual in the syslog.
History
Updated by Andy Brown about 11 years ago
- Status changed from New to Need feedback
- Assignee deleted (
Adam Sutton)
This sounds like its related to the EPG entry for the program it is trying to record, but is indeed unusual and I've not heard of this issue before.
When you schedule the recording, is that from the web-UI or from XBMC/another client.
When the recording is scheduled, does it have a 'valid' entry in your EPG, i.e. does it show the correct start and end time of the program you're recording?
Are you using the autorec, add manual recording or series linked recording methods?
If you can answer the above we should be able to narrow down whats going on here.
Updated by Mike Brickman about 11 years ago
All recordings are set up using the Web-UI. As far as I am aware, the correct start and end times are being shown and there is a valid entry in the EPG. The problem has occurred with both series-link and autorec schedules.
The problem has happened with around 10 recordings this week so I have changed the EPG grabbing from 10 mins to 24 hrs to see if things settle down. My suspicion is that the recording process is being unhinged by a new EPG entry for the program currently being recorded. Have there been any changes in this release that might cause this?
Updated by Adam Sutton about 11 years ago
Please create a debug log when this happens (can't think if the 3.2 code will give the necessary info, but its a starting point). It does sound like the existing EPG entry is being extended in time somehow and causing the thing to fail. Or that the timer for completion is somehow being removed. This does ring a bell, I think someone (possibly John T) mentioned this to me before. But it was a one off and so we never got to the bottom of it (he's also a XMLTV user, I assume that's what you're using, so some correlation?).
Adam
Updated by Adam Sutton about 11 years ago
Well I think I've spotted one bug, though not directly related to this one. I think that if the time of an entry does extend (i.e. it overruns) this is not properly handled!
Updated by Adam Sutton about 11 years ago
Ah, I think I might have spotted it. It looks like dvr_entry_remove() can be called from dvr_event_replaced() (which is called when the EPG believes an event has been replaced with a new one). And dvr_entry_remove() will indiscriminately (doesn't check if a recording is in progress) disarm the dvr entry timer. In other words the recording will never complete!
Updated by Mike Brickman about 11 years ago
OK, let me know if there is anything more you need from me. I will stick with 24hr updates for now to check that the problem goes away and revert to 10min once your fix has been release.
Updated by Adam Sutton about 11 years ago
Mike,
Are you able to compile the code yourself to check a patch?
Adam
Updated by Adam Sutton about 11 years ago
Hmm, except that bit of code should never be reached under these conditions, because it's specifically supposed to ignore stuff that's not scheduled (as opposed to complete/in-progress).
Updated by Mike Brickman about 11 years ago
I'm a Delphi/Windows programmer in my professional life which is complicated enough without having to branch out into linux c in my spare time. So unfortunately I and not setup to compile patches.
Updated by Andre Liebe almost 11 years ago
I think this one bugs me too. Some of my recordings keep going on way over the shown/detected finish time. This only happens with entries created by autorec.
Sometimes, when multiple recordings were creatde by autorec (e.g. "TV Series X"), hts seem to randomly pick one entry for recording (displayed in webgui as running recording and chosen filename) which starts with the time of the first entry and lasts until the last entry was scheduled to finish. Some of the other occurences will then be marked as failed with "time missed" or get recorded twice.
TV Series X - 09:45-10:15
TV Series X - 10:15-10:45
TV Series X - 13:05-13:35
TV Series X - 13:35-14:05
TV Series X - 20:15-20:45
TV Series X - 20:45-21:15
I'm running Build 3.4.27~gfbda802 an arch linux 64bit and I'm able to apply pathes against the aur package on request.