Feature #766
Extracting title and episode number from title in EPG in Auto Rec
0%
Description
In polish tv titles in EPG often contains misc prefixes (cycle name) before actual movie title - for example:
"Megahit: Matrix" - where "Megahit" is prefix added each week to saturday night movie title.
So when I create Auto Rec for "movie/drama" about 20:00 in Saturday I get many recordings with unrelated movies but unfortunately starting with common prefix "Megahit".
It is very unconvenient, because sometimes prefixes are very long, so while browsing filenames/directories main title is truncated or even invisible but unimportant prefix is entire visible.
It could be implemented as simple regular expression defined in Auto Rec entry for example: "Megahit: (.*)" or even ".*\:(.*)"
The same method could be used for extracting episode number from title. We have for example title:
"House, MD, episode 10" (in Polish: "Dr House, odc. 10") so simple regexp like ".*episode (.*)" could extract episode number.
History
Updated by Hein Rigolo about 13 years ago
- Category set to EPG
- Priority changed from Normal to Low
- Target version set to 3.0
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.
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
Updated by Damian Gołda about 13 years ago
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".
Updated by Damian Gołda about 13 years ago
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?
Updated by Hein Rigolo about 13 years ago
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.
Updated by Martin Mrvka about 13 years ago
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.
Updated by Hein Rigolo about 13 years ago
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.
Updated by Martin Mrvka about 13 years ago
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.
Updated by Hein Rigolo about 13 years ago
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
Updated by Adam Sutton over 12 years ago
- Status changed from New to Rejected
- Assignee set to Adam Sutton
While I can see some merit in this and I may consider looking into it at a later date, at this stage I think Hein's recommendations are correct. This is a problem with upstream data and should be fixed there (admittedly fixing EIT data is not likely to happen).
I have added several improvements to the EPG code (will be in mainline code later this week), but parsing out stuff from titles is generally something I want to avoid. It's prone to failure, especially without much user customisation for handling language diffs etc... Which would probably confuse most users.
If people still want to see this and can give a clearer idea of what is required, then re-submit and I'll reconsider.
Adam