Bug #1561
closed
Added by Giovanni Borri about 12 years ago.
Updated about 12 years ago.
Description
Hello Adams,
I have seen some fix by you about what i will say later but i don't remember where.
Follow a description of what happens:
I have set an autorec for a cartoons series for my kids.
After recording the stream i will move the episode on my library in order to have all the episode and season ordered.
In this way after recording an episode the file disappear as soon as it will be moved to the library.
All the recording are marked as failed. This is a problem because when autorec will be fixed for #1486, it will not be possible to set correctly the autorec of the series.
for me the log of the autorec should work to manage the recording procedure not to see if the file persist on disk or not.
The problem should be if the recording start and the file will not be present on disk (full, permission problem), but i think that the failure should be related to file handle.
Giovanni
- Status changed from New to Need feedback
Sorry I do not understand what bug has been reported here? The fact that recordings for which the actual recording is unavailable are marked as such?
This is not a bug, it was added so these recordings could easily be filtered from the "available" set in clients such as XBMC (and the WebUI).
Adam
hello Adam,
there's a side effect. If I move the recording stream from recording location to my xbmc library every recording is marked as failed. In this way the autorec feature doesen't work, becouse it try to re-register every episode. I think that you have to mark as failed only if you can't open filehandle, o can't write to file (no space left on device, no directory available etc), not if you can't find the file.
Giovanni
- Status changed from Need feedback to Invalid
No such checking exists, the only autorec dup detection that occurs (presently) is based on upstream episode identifiers (basically just UK Free* CRIDs at present).
Nor does this change affect that in anyway, the entry is still marked as completed in the log, but with the additional info that the associated file is missing.
If you can see a clear example of TVH doing the wrong thing can you provide a step by step way of repeating.
Adam
hello Adam,
try to configure "Post-processor command:" with a mv command in order to move the file some where else from dir configured "Recording system path:".
what happens is that after recording has finished the log is marked as failed (red icons) in upcaming recording.ì and then moved on Failed recording.
Giovanni
Sure, I do that as well and I want those entries to be removed from my "available" set in say XBMC (since they can no longer be played via TVH and usually it means they're now part of my library proper), but this has no impact on autorec performance.
Possibly the confusion here is that they are listed in the "Failed recordings" tab, this is just a wording issue, this covers not just failed recordings but also (now) those that can no longer be accessed. Internally the recording is still logged as completed (and would be counted in any dup detection should it exist).
One day I'll make it possible for postproc rules to report the files has been moved (so you can possibly access via both means) OR that its been removed (if you no longer want to access via TVH - my case). But as it stands I don't see this as a bug.
Adam
ok. if it's logged ad complete that's fine.
the only cosmetic issue is that if you are looking for recording and want to delete an instance because the instance is not good (movie cutted because of wrong schedule from broadcaster) it will be a bit tricky.
a different tab? do you think would be a solution?
thanks
Giovanni
Longer term I will hopefully find some time to do a revamp of the DVR code and take such things into consideration. But short term we'll probably leave as is unless lots of people complain its too confusing.
Adam
ok, for me is enough.
thanks
Giovanni
Also available in: Atom
PDF
Updated by 
Updated by