Terje Bratland wrote:
> This is from my guide.xml:
>
> <programme start="20170821210000 +0200" stop="20170821220000 +0200" channel="C More Series">
> <title lang="nb">Game of Thrones</title>
> <desc lang="nb">Amerikansk eventyrserie fra 2017. Et stort slag venter i sjuende sesong om det fiktive kontinentet Westeros. En knallhard Cersei har akkurat inntatt jerntronen, men fiender truer i alle himmelretninger. Daenerys' flåte seiler over havet, samtidig som Jon fortsetter å samle troppene i nord(n)</desc>
> <credits>
> <actor>Lena Headey</actor>
> <actor>Peter Dinklage</actor>
> <actor>Nikolaj Coster-Waldau</actor>
> <actor>Emilia Clarke</actor>
> </credits>
> <date>2017</date>
> <category lang="nb">Serie</category>
> <episode-num system="xmltv_ns">6.5/7.</episode-num>
> <rating system="NO">
> <value>15</value>
> </rating>
> </programme>
>
> And it gives the output "s7.e6"
That is correct. The xmltv_ns is a 0-index, so season 1 episode 1 is:
<episode-num system="xmltv_ns">0.0.</episode-num>
For those interested, here's the relevant bit from the DTD:
<!-- Episode number
Not the title of the episode, its number or ID. There are several
ways of numbering episodes, so the 'system' attribute lets you specify
which you mean.
There are two predefined numbering systems, 'xmltv_ns' and
'onscreen'.
xmltv_ns: This is intended to be a general way to number episodes and
parts of multi-part episodes. It is three numbers separated by dots,
the first is the series or season, the second the episode number
within that series, and the third the part number, if the programme is
part of a two-parter. All these numbers are indexed from zero, and
they can be given in the form 'X/Y' to show series X out of Y series
made, or episode X out of Y episodes in this series, or part X of a
Y-part episode. If any of these aren't known they can be omitted.
You can put spaces whereever you like to make things easier to read.
(NB 'part number' is not used when a whole programme is split in two
for purely scheduling reasons; it's intended for cases where there
really is a 'Part One' and 'Part Two'. The format doesn't currently
have a way to represent a whole programme that happens to be split
across two or more timeslots.)
Some examples will make things clearer. The first episode of the
second series is '1.0.0/1' . If it were a two-part episode, then the
first half would be '1.0.0/2' and the second half '1.0.1/2'. If you
know that an episode is from the first season, but you don't know
which episode it is or whether it is part of a multiparter, you could
give the episode-num as '0..'. Here the second and third numbers have
been omitted. If you know that this is the first part of a three-part
episode, which is the last episode of the first series of thirteen,
its number would be '0 . 12/13 . 0/3'. The series number is just '0'
because you don't know how many series there are in total - perhaps
the show is still being made!
The other predefined system, onscreen, is to simply copy what the
programme makers write in the credits - 'Episode #FFEE' would
translate to '#FFEE'.
You are encouraged to use one of these two if possible; if xmltv_ns is
not general enough for your needs, let me know. But if you want, you
can use your own system and give the 'system' attribute as a URL
describing the system you use.
Systems proposed in 2013 to refer to common metadatabases in a
common way:
'themoviedb.org' with the content 'movie/1234' to refer to a movie,
'thetvdb.com' with the content 'series/123456' to refer to a series,
'thetvdb.com' with the content 'episode/123456' to refer to one episode
of a series and 'imdb.com' with the content 'title/tt123455' to refer to
a movie, series or episode.
-->
<!ELEMENT episode-num (#PCDATA)>
<!ATTLIST episode-num system CDATA "onscreen">
Terje Bratland
I understand (most of) this. But my problem is that even though it says s7.e6 it's not recognized as season 7, episode 6 by TVHeadend. It says I have no seasons in my database, only episodes.
Robert Cameron
Terje Bratland wrote:
> I understand (most of) this. But my problem is that even though it says s7.e6 it's not recognized as season 7, episode 6 by TVHeadend. It says I have no seasons in my database, only episodes.
If the info dialog in Tvheadend is displaying "s7.e6", then Tvheadend is in fact reading the season information and correctly parsing the XMLTV.
Perhaps there is some misunderstanding about terms here? What are you expecting a result to be? How is it not being recognized as a season in your database, even though it is displaying as one?
I'm not sure I fully understand Tvheadend's terminology, and it seems to contradict itself. I just ran my grabber, and this is what I get:
> 2017-08-21 13:15:53.002 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: grab /usr/bin/tv_grab_zz_sdjson_sqlite
> 2017-08-21 13:15:53.011 spawn: Executing "/usr/bin/tv_grab_zz_sdjson_sqlite"
> 2017-08-21 13:15:53.836 spawn: Opening the local database
> 2017-08-21 13:15:53.865 spawn: Obtaining authentication token for Schedules Direct
> 2017-08-21 13:15:54.581 spawn: Schedules Direct account expires on 2017-11-26T19:50:14
> 2017-08-21 13:15:54.581 spawn: Schedules Direct data last updated on 2017-08-21T18:15:51
> 2017-08-21 13:15:54.582 spawn: Downloading data from Schedules Direct
> 2017-08-21 13:15:54.583 spawn: not downloading lineups from Schedules Direct (data current)
> 2017-08-21 13:15:54.583 spawn: not downloading channel and station maps for lineup USA-CA04768-X (data current)
> 2017-08-21 13:15:54.584 spawn: not downloading station schedule hashes (data current)
> 2017-08-21 13:15:54.598 spawn: not downloading daily schedules (data current)
> 2017-08-21 13:15:54.813 spawn: not downloading programs (data current)
> 2017-08-21 13:15:55.079 spawn: not downloading programs for supplemental data (data current)
> 2017-08-21 13:15:55.079 spawn: Processing data and creating XMLTV output
> 2017-08-21 13:15:55.096 spawn: 177 channels processed
> 2017-08-21 13:16:33.003 epgdb: snapshot start
> 2017-08-21 13:16:33.396 epgdb: queued to save (size 62980276)
> 2017-08-21 13:16:33.396 epgdb: brands 0
> 2017-08-21 13:16:33.396 epgdb: seasons 4735
> 2017-08-21 13:16:33.396 epgdb: episodes 68188
> 2017-08-21 13:16:33.396 epgdb: broadcasts 86134
> 2017-08-21 13:16:33.396 epgdb: save start
> 2017-08-21 13:16:34.239 epgdb: stored (size 7612576)
> 2017-08-21 13:16:47.772 spawn: 90761 program schedules processed
> 2017-08-21 13:16:47.772 spawn: Pruning the local database
> 2017-08-21 13:16:50.955 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: grab took 58 seconds
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: parse took 11 seconds
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: channels tot= 177 new= 0 mod= 4
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: brands tot= 0 new= 0 mod= 0
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: seasons tot=81842 new=81842 mod=81842
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: episodes tot=86131 new=48552 mod=48553
> 2017-08-21 13:17:03.365 xmltv: /usr/bin/tv_grab_zz_sdjson_sqlite: broadcasts tot=86131 new= 3 mod= 3
As you can see, there's a discrepency between what is reported by my grabber (the lines prefaced with "spawn"), Tvheadend's XMLTV parser (those prefaced with "xmltv") and Tvheadend's internal EPG (those marked "epgdb"). None of them seem to match, and the number of items is not consistent.
Perhaps it's time for a refactoring or restructuring of Tvheadend's EPG DB, making it a bit easier to extend, and allowing all functions of it to apply regardless of source. (Series-link type recordings, incomplete mappings from XMLTV to Tvheadend, allowing other grabbers/sources to directly interact with the database ...)
Terje Bratland
My problem is the following:
When I run a scan, I get 0 seasons, only episodes. And TVHeadend is recognizing s7.e6 as an episode, not a season and a episode.
So I'm unable autorecord based on episode numbers, and unable to sort epg by episode.
My scan: (Disabled most channels for a quick run)
http://i.imgur.com/HtX4lcs.png
This channel has just gotten EPG-data from the scan above.
http://i.imgur.com/oNhChof.png
http://i.imgur.com/97tEag7.png
Robert Cameron
What you say is happening seems to match your logs, but your images from the info say something different. So, try this: reset your guide.
In the Tvheadend settings, make sure that Tvheadend is not set to save the EPG. Then, stop Tvheadend. Next, delete the epgdb.v2 file in your Tvheadend settings directory. Since you are using a static grabber, now download a fresh xmltv file from your web source. Now you can restart Tvheadend, and manually re-run your grabber. This should force Tvheadend to essentially re-initialize its guide, ensuring the data is not stale,
Keep in mind this will only affect guide listings from the reset forward, and previously recorded or scheduled items may still be using the old guide data. However, this is the only way I can think of finding a solution.
Otherwise, there are only 1 other thing I can think of: this is a bug in Tvheadend's EPG backend. (I origi ally thought it could be xmltv related, but your source looks fine. However, you may want to try validating your xmltv source, just to be sure that it's not the culprit.)
Terje Bratland
I tested your solution now, but ended up with the same result...
So it might look like there's a bug in Tvheadend. :(
But it's weird that I haven't found anything similar while googeling this...
Robert Cameron
Did you validate your xmltv against the DTD? Perhaps it might be an issue with your source.
Terje Bratland
I did. All good on the xml-file...
Terje Bratland
Could you please try to validate my xml?
Terje Bratland
I found out that by using dd_progid I also get seasons.
<episode-num system="dd_progid">EP00003163.0109</episode-num>
But I have no idea how to obtain this information. (Now I just putted some numbers there)
How can I find dd_progid-information?
Robert Cameron
I'll give it a check later today. As far as the "dd_progid", I believe that's the DataDirect ID, which comes from your upstream provider. Who is your guide provider? How is the source guide data provided? Is WebGrab+Plus creating its own xmltv, and if so, perhaps it's a problem with the xmltv that it generates.
Robert Cameron
So I didn't run the data through a validation yet as I'm just on my iPad today, but it looked OK just visually inspecting it. However, I did notice that less than half of the entries that included episode information had no season, only an episode number.
If the entries not showing any season information are assigned a season number, I can't figure out why. My only guess is that Tvheadend's parser does not like xmltv that only sometimes gives a season number; perhaps it is expecting to always have a season number, or never have one, but not both?
Another hint just occurred to me, though. You say you can't record based upon episode number because it's not reporting seasons, but I've never seen an option about seasons when recording. Doesn't episode number imply/include a season if present? So, if you say record only if different episode number, S01E02 and S03E02 will both record because they have different episode numbers? This has been my experience, but has it happened to you?
(I may not have experienced this if it occurs, though, because I generally also set my autorecs to record if new, meaning that my XMLTV programmers have a "new" element in them to help determine new episodes beyond just having a different episode number.)
