Tvheadend

Hein Rigolo wrote:

You could do this with a post recording script. The filename is available so you can run a script after each recording to rename the file to whatever you like.

Yes, but file after renaming is not available in Recordings menu in XBMC, because Tvheadend knows old path to filename.

If you like to have the names already adjusted in the epg then make sure you use xmltv to populate the epg and adjust the names in the xmltv feed.

Implementing all these kind of rules, logic etc etc in the web gui will make things very complicated. What if some channels need different rules etc. How would you maintain this via the gui? Etc etc

It would be sufficient to add two optional fields to Auto Rec entry: one for regexp pattern for extracting actual title, and second for pattern for extracting episode number. Just like now is "title regexp".

I could try to implement this, and provide patch, but I don't now tvheadend code yet.
Could you give me any clue which parts should be modified, please?

Instead of using the recordings menu you can export the tvheadend recordings directory to your xbmc as a location where files can be found. That way you do not need the recordings menu anymore.

I still think that making an update to your xmltv feed is much easier to implement then to go through all the tvheadend code. If you really would like to implement this in code then have a look at the dvr directory. There most code around recordings is located.

I would say, there are two options in general.

1) Import the epg as is, and then let the user decide
2) Parse and filter the epg when importing

ad1)
The advantage is, that the epg is stored in the original form. the client (user, xbmc, webinterface, showtime...) can decide. But this is also a major disadvantage. Complex rules may be applied by the user or different clients modify the same information in an different way and also the information is not consistent across different tv stations or epg sources.

ad2)
For sure, the disadvantage is that we still have complex rules, but now in the code - not easily changeable unless they are configurable. However, the epg is now clean and, as you wrote, episode information could be parsed out if existent.

Well, we do not want to have, or maintain, channel specific code n tvheadend. So if you need to have some parsing logic it should be generic so that it can be applied to any and all eit data that is received. But I suspect that that is too difficult to make. That is why is suggest you use xmltv to import your epg into tvheadend and make sure that all the data is just like you want to have it. And there are tools around that can extract the eit data and convert it to xmltv formattee files. You can then parse/update/enhance those file as much as you like.

Yeah, that's true. channel specific parsing should happen outside. Unfortunately, I can't access the eit data outside since tvheadend is blocking the adapter. That's why I tried to find another solution. But anyway the eit data is not very good for episodes, since most of the time the episode information is missing. So a commercial xmltv provider seems to be the only way.

Well, just shutdown tvheadend at a quiet time, like in the middle of the night, and run a tool to grab the dvb eit data. Or get an extra adapter just to get the data. Might be cheaper then a commercial xmltv provider.

Or write your own grabber that converts the listings that most stations or new papers publish to an xmltv feed. Are you sure there an such grabbers already?

Hein