Tvheadend

Thanks,

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"?

• 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.

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.

Sebastian,

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. https://www.lonelycoder.com/redmine/issues/1087

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

Adam

Adam,
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".

Hmm,

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.

Adam

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?

Posted on the XBMC/PVR forum

Ok,

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.

Adam

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.

About the "Time missed" recordings, I was wrong: they are filtered by the GetDVREntries method in the [url=https://github.com/opdenkamp/xbmc/blob/master/xbmc/pvrclients/tvheadend/HTSPData.cpp]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!).

No,

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.

Adam

• 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.
  Regards

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.

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.

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.

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.

Thank you very much, this is great!