Feature #1083

Only list the actually available recordings under XBMC

Added by Sébastien Aubry almost 11 years ago. Updated over 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Currently, under XBMC, when I display the list of my recordings, I get every program which has been scheduled for <DVR log retention time> days, even :
  • if the associated file was manually deleted (e.g. by my autodelete script)
  • if the recording was not made ("Time missed in the HTTP interface") because no tuner was available at this time
    The only recordings which do not show are those which were deleted through the HTTP interface or through XBMC.

Pressing "Ok" on a deleted recording inside XBMC will cause nothing but a new Tvheadend entry in the syslog:
Aug 5 22:29:08 pchc tvheadend[1583]: HTTP: /dvrfile/12334 -- 404

I would really like to see only the recordings available for watching. The list provided to XBMC should not be the same as the list seen in the HTTP interface under "Recorder schedule" (which must contain everything, including the missed recordings).

This would imply to check the recordings file to see if they still exist:
  • either at Tvheadend startup but it does not occur very often on my setup (sometimes several weeks before I reboot for a kernel or driver update)
  • or on XBMC request but it might take too much time
  • or on a regular basis (like EPG grabbing)

It could also be done by the XBMC plug-in in background but IMHO the best way is to put that on the TvHeadend side since the manual deletion of recordings is allowed.

I am using XBMCBuntu Eden (vanilla 11.10), XBMC-PVR from Pulse (now build 95) and TvHeadend 2.99-9~oneiric (



Updated by Adam Sutton almost 11 years ago

  • Status changed from New to Need feedback
  • Priority changed from High to Low

My initial thoughts:

I don't think this is the right way to do this. Personally I prefer to let the client make the decision about what/how to display stuff to the user.

At first glance it seems straightforward enough that if a recording completed and you removed file you'd not want that displayed. Using such a setup is quite useful with newer EPG/DVR code as it can save disk space while still informing the DVR what you've previously recorded (and thus don't want re-recorded).

However if you "hide" that from XBMC, you then force users to use the TVH UI to remove those if they decide they do want to re-record the show. This is definitely NOT something that I want to happen.



Updated by Sébastien Aubry almost 11 years ago


I must admit that at this time, I use the TVH UI to set up my recordings (basically I search the titles of all the good movies every week and then record them) and XBMC to watch them :-)

In some cases, you only need the recordings really available for watching. In some special cases, I can understand that you want to schedule some new recordings using the full recording log. XBMC offers both a "Recordings" and "Programming" list, which are not the same. Cannot you see the recording log inside XBMC in another place than the "videos list"?

Couldn't we separate :
  • the list of the past recordings (full log, in which you should still show those deleted through the UI currently not the case and outside from the UI)
  • the list of the recordings still available (for which there ARE files available on the disk)

I could have posted this message on the XBMC forum but this is a TvHeadend feature (if not already available) to provide both these lists, and then the right list can be picked inside the XBMC PVR-TvHeadend connector.

In my opinion, this is one of the only things to fix in my XBMC+TvHeadend setup. This is quite weird when you select a show for playing and nothing happens.


Updated by Adam Sutton almost 11 years ago

  • Category set to PVR / DVR
  • Status changed from Need feedback to New
  • Assignee set to Adam Sutton


I think you may have somewhat misunderstood me, my fault for not being clear :)

I completely agree with your ideas with respect to possible changes in the way the data is presented, however the point I was trying to get across is that this is client side code. It is the only thing that can make decisions about "how" to present the data, TVH simply ensures it has access to all necessary info.

TVH provides a single message to XBMC to inform it about new/existing DVR entries (note: the name may seem confusing, since this is a TVH->XBMC message):

id - unique ID within TVH to reference this item
channel, start and stop - obvious
title, description - (optional) also obvious.
state - can be one of "scheduled", "recording", "completed", "missed", "invalid"
error - in the case of "completed" this is set if the recording was unsuccessful and gives basic indication of the failure.

So if you think, and I agree, the XBMC interface needs improvements (filtering/diff views of recordings etc..) then that is the correct place to report it.

That being said, you are definitely correct on one point. I do not believe TVH currently reports the presence/availability of a completed recording (i.e. file may have been removed unbeknown to TVH).

I will update the DVR code to report this information, but it will also require XBMC to filter it accordingly as I can't simply remove the entry from the list. Note: depending on how I do things its possible that it will already do the filtering required.



Updated by Sébastien Aubry almost 11 years ago

Dear Adam,
I completely agree with you. TVH has to report everything and then the filtering can be done client-side, with the appropriate events on recording creation and deletion: if I manually remove a recording from the file system, TVH would have to send XBMC a "dvrEntryRemove" message.
I would be happy to contribute. I can perhaps post a message to the XBMC-PVR forum to ask for the filtering we are discussing in the TvHeadend connector.
Also, wouldn't there be a way to separate the log retention delay (default is 30 days) from the recordings which are being physically kept on the hard disk (which could be 6 months old)? This would perhaps be difficult due to the way TVH currently manages the stored recordings. This is perhaps another related demand.


Updated by Adam Sutton almost 11 years ago


I was slightly incorrect in my statement about there being only 1 message about dvr entry state, still a bit blurry eyed ;)

Actually it would send a new dvrEntryUpdate, to update the state of the current entry (i.e. to say the file is removed). However exactly how that would happen is NOT entirely clear at this stage. Since we don't really want to periodically check the FS for removed files. But there are event based interfaces to this sort of thing in linux (inotify), so I could look into that.

dvrEntryDelete is actually called when an entry is removed from the database and this is definitely different to the case of the file only being removed, which would be an "update".

I think your probably correct about the log/file retention policy, I think that is another feature entirely. However I will say that I have plans, time permitting, to do some significant re-working of the DVR code to provide much greater flexibility.

I've opened a general DVR improvements issue to cover mine and others thoughts on things that could be included. Probably best to add your thoughts on there.

And yes if you want to submit something to XBMC-PVR that would be best way to proceed on the user interface.



Updated by Sébastien Aubry almost 11 years ago

I agree, but what I wanted to point out is the fact that when you "delete" a recording from the XBMC UI, it is deleted from the database. It should however give the same result as when you remove the file from the file system: the log should still list this file with a status like "File removed".


Updated by Adam Sutton almost 11 years ago


Ok I misunderstood that point. I'm not sure about this.

I think it would probably be better to do the following (apologies if this is what you were actually proposing).

1. Extend the DVR api so that the client has option to delete just the file (but leave the DB entry).
2. Update XBMC UI to give user the choice of whether to just remove the file OR the entire DB entry.

Currently, and I think the default, would be to completely remove the entry from the DB as this is what people generally expect to happen when they delete an entry from XBMC.

But having the option to only remove the file is not a bad one, and that would be a report on both XBMC and TVH and would require us to co-operate.



Updated by Sébastien Aubry almost 11 years ago

Hello again,
I am not sure I agree: in every other Media Center, the only purpose of removing a recording is mainly freeing some disk space. The database entry removal can be considered as log management which is a kind of tricky feature that should not be the default. Selecting to delete a recording from the client should remove the file but, by default, not lose the track that this program was correctly recorded then manually deleted.
All this discussion shows that the "recording log" is not the same thing as the "current list of the available recordings" and should perhaps be managed separately. The latter could perhaps be built by parsing the contents of the recordings folder and then matching them with the database?


Updated by Sébastien Aubry almost 11 years ago

Posted on the XBMC/PVR forum


Updated by Adam Sutton almost 11 years ago


I think we'll have to agree to disagree on that point. In almost every other system (commercial PVR's, XBMC, etc...) I've used deleting a recording means removing it from the history (DB) and removing it from the disk.

As this is currently what TVH does and XBMC expects, this will continue to be the default. However I'm still open to the idea of having an option to NOT remove the DB entry and just remove the file from disk, as I can see definite benefit in that.



Updated by Sébastien Aubry almost 11 years ago

Any solution will be fine :-)
The main thing is to fix the media list so that we do not get these 404 errors anymore.
Thank you for your help.


Updated by Adam Sutton almost 11 years ago

  • Status changed from New to Accepted

Updated by Sébastien Aubry almost 11 years ago

About the "Time missed" recordings, I was wrong: they are filtered by the GetDVREntries method in the [url=]pvrclients/tvheadend/HTSPData.cpp file[/url]. I have made some tests and that seems to work well.
There may be another bug because not being able to play a recently recorded file happened to me in the past. I will report it if I find it again.

The only thing to add now is a "DELETED" status on the files which were manually deleted from the file system. I do not think anything can be done about this from the client-side (excepted testing all the file URLs but this would not be efficient!).


Updated by Adam Sutton almost 11 years ago


I completely agree that TVH needs to make the information available to the client, that's the only sensible approach. But the client will be responsible for what it does with that info.

I have a feeling that if I do thing the way I'm thinking XBMC may automatically filter these out. However I've not tested it or checked the code.

Also its not a trivial matter to add in background checks on all the recordings (to check for deletion), so it won't happen right away.



Updated by Sébastien Aubry almost 11 years ago

Hello Adam,
I understand that it is complicated. But yesterday you seemed to agree with this solution :-)
  • Another way to do it would be to implement the "autodelete" feature which would delete the oldest recordings if the free space is below a given amount. I run it as a postprocess script, it behaves very well and it could be integrated as an "automatic postprocess script" if this option is enabled.
  • I could also update my script to give the deletion information to TvHeadend or to perform the deletion through TvHeadend. Would there be an easy way to do it such as using the HTTP protocol?
  • As a temporary ugly workaround, I could update the log retention time in order to make it "match" my disk capacity (about 7 days!). This way, the log would more or less match the available files on my hard disk.

Updated by Sébastien Aubry almost 11 years ago

About "I have a feeling that if I do thing the way I'm thinking XBMC may automatically filter these out.": in my opinion, this would be a good default behaviour not to see these dead links in the XBMC Recordings folder.


Updated by Sébastien Aubry almost 11 years ago

Ok ... I have read the manual and I think that we can do something using the HTSP protocol . I will see if I can make a new autodelete script which will perform the deletions through TVH.


Updated by Adam Sutton almost 11 years ago

I think its fine to monitor for disk based changes to automatically detect when files in the DB are removed. This is the most robust option, because others may simply remove or (in my case) move the files for more persistent storage.

That doesn't mean we can't have a bit of both.

Also you're better off reading src/htsp.c rather than the doc. The document is somewhat out of date and in several aspects relating to XBMC integration its definitely missing key stuff.

We will sort out docs when we get a chance.


Updated by Adam Sutton over 10 years ago

  • Tracker changed from Bug to Feature

I've looked through the code and this is certainly doable, however the change is non-trivial and therefore I'm going to put off until after 3.3 and move to FR.

As this isn't really a bug with TVH, just an unexpected use case.



Updated by Sébastien Aubry over 10 years ago

Thank you Adam.
The other way I see it would be to write some "tvh_rm" and "tvh_move" commands which would delete the recording file through the API (this is why I asked you about the way to use the API in Python a few weeks ago). This way, the database would always be up-to-date.
My main concern is that every other Media Center will fill your hard disk and then delete the oldest recordings, while XBMC+TVH will keep the last 30 days of recordings, if your hard disk is big enough :-) I have just bought a 1.5TB hard disk as a workaround but will try to work on this issue when I find some time.


Updated by Adam Sutton over 10 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:accc01db56b50cdf303d382dd8647323c704e262.


Updated by Sébastien Aubry over 10 years ago

Thank you very much, this is great!

Also available in: Atom PDF