Hi,
I get the following message right at the begining, so no guide this time:
[ Info ] channel (xmltv_id=DK 24 Nordjyske) site -- DK.TIMEFOR.TV -- mode full
[ Error ] time parsing error : String was not recognized as a valid DateTime.
[ Error ] stoptime time scrubbed : 1447048800
[ Error ] computer date/time format: 09-11-2015 16:06:06
[ Error ] execution stopped
I have tried the latest siteinipack and the separate download (Dated 28-10-15) as well.
INFORMATION:
1. WG++ v 1.1.1 with upgrade 55
2. Windows 7 64 bit
4. http:\\www.a123.dk\webgrabplus\info.zip
TIA
Is working with the latest beta,
So try to use that one. I don't know if it should work under V55.27.
I think the @MinSWversion of this siteini should be set to V56.08 (but not sure). Jan could elaborate on that.
Bottom line, using the latest beta and you will be fine.
If you need V55, you should add
index_start.modify {calculate(format=utctime)}to the siteini and it will also work.
It is just because the new beta "understands" the unix time stamp that is used by this site. But don't know when this feature was introduce exactly.
That certainly helped.Thanks a lot
I have added more channels, but for some channels (eg xmltv="DR DR1") all the times are:
<programme start="20151109000000 +0000" stop="20151109000000 +0000" channel="DK DR1">
I have uploaded a new file info.zip with my current settings, this time including a guide (wgTimeFor.xml)
Use the link in post #1
I did try to add the suggested line to the ini file, but with no luck.
TIA
Fixed new version online.
I can confirm, that it now works.
Is there a way to get the role attribute of the actor field? Not that important, would be nice, though.
I think you can change (in the siteini)
actor.modify {remove(type=regex)|(</strong><br>.*)} * remove any actor role (after the </strong><br>)into
actor.modify {remove(type=regex)|<[^>]*>}A step in the right direction
I get:
<actor>Juliette BinocheTereza</actor>
should be:
<actor role="Tereza">Juliette Binoche</actor>
Currently this will be as close as you can get.
WG++ doesn't (yet) supports the role feature of xmltv.
I have now moved WG++ from my work pc to my htpc and found out, that times were 1 hour too early. A fix (inifile) seems to be
|timezone=UTC| -> |timezone=UTC+01:00|
1) Is this the correct way to do it?
2) DST (Daylight Saving Time). Is this taken care of? (by |cultureinfo=da-DK|?)
No, the sitetimes are in UTC, so keep that.
1. Is that htpc computer set to the right local timezone (inc DST)?
2. When do you see the time difference? On the EPG viewer of your mediacentre?
3. Are the times in the xmltv file different from the ones on your work pc?
If the answers are 1. Yes, 2. EPG viewer 3. No ,
then your problem is that the xmltv importer of your Media Center doesn't handle the timezones correctly (Happens alot !!) Which MediaCenter/xmltv importer are you using?
In case it interest you , read http://www.webgrabplus.com/content/times-time-zones-and-dst-corrections.
As a fix you can use either your solution utc+01:00 or http://www.webgrabplus.com/sites/default/files/download/utility/xmltv_time_correct/xmltv_time_correct.zip
Jan
I use DVBViewer and Xepg (www.a123.dk) as xmltv importer (I am the author of the latter).
System times (Windows 7) are set properly on both the work pc and the htpc. Files and output are totally identical on both pcs.
With |timezone=UTC+01:00| I get
<programme start="20151115214500 +0100" stop="20151115231500 +0100" channel="DK TV 2 Charlie">
<title lang="da">Vi har det jo dejligt</title>
This is the correct Danish start time 21:45 according to source site. This works.
With |timezone=UTC| I get
<programme start="20151115204500 +0000" stop="20151115221500 +0000" channel="DK TV 2 Charlie HD">
<title lang="da">Vi har det jo dejligt</title>
I think I now understand! 20:45 is the UTC start time as correctly indicated by +0000 (not so usuall according to your link).
Fortunatly Xepg has the ability to add x minutes to all times when processing a file.
I will keep |timezone=UTC| and then let Xepg add 60 minutes. This works as well.
Xepg ignores any time offsets like the the +0100. In this case maybe it shouldn't?
Well, none have ever complained about that.
What will WG++ deliver for start in the upper case assuming DST (Daylight Saving Time) has happened?
TIA
Well, YES Xepg should the +0100 (or +0000 in this case) into account. Only if your computer is in the same timezone as your siteini, you could leave it out I think.
When DST happens, the +0100 will be adjusted to the correct value after the DST,so +0200. And your guide will be then 2 hours off.
So if you are the author of Xepg, it shouldn't be that difficult to add the time diff to the dst time. The actually thing you should do to make your importer robust/correct, is to read the time in the xmltv file eg. 20151115214500 and apply the UTC offset (eg. +0100, in your case it is only +0000). So the time you should get is then 20151115204500 (this is the actual time in UTC). And if you have the time in UTC, you have to convert it to the timezone of the current computer.
In short:
It should be:
(xmltv) 20151115204500 +0000 ==> (UTC) 20151115204500 ==> (local timezone) 20151115214500 +0100
The reason why you didn't had any issues with it, is that the timezone of the site (=siteini) was probably always the same as your pc.
(xmltv) 20151115214500 +0100 ==> (UTC) 20151115204500 ==> (local timezone) 20151115214500 +0100
And if you can see, because the first and the last are the same, you can "skip" the correct conversion, without having any issues. So that is why you didn't see any issues before I presume.
Thanks for this very clear explanation. I don't understand the following, though:
1) Shouldn't it subtract 1 hour from the time offset?
Since it is a bit confusing, that both the offset and the DST is 1 hour, I have constructed an example to illustrate what I mean:
(Let's skip year, month and date for simplicity)
UTC time = 1000, pc's timezone = 0300
This should give 1300 for no DST and 1400 for DST (assuming DST=1 hour).
Using timezone=UTC in WG++
No DST:
file: 1000+0000, adjust for pc timezone: 1300 ---->OK
DST:
file: 1000-0100, calculate "UTC": 1100, adjust for pc timezone: 1400 ---->OK
Using timezone=UTC+03:00 in WG++
No DST
file: 1300+0300, calculate UTC: 1000, adjust for timezone: 1300 ----->OK
DST
file 1300+0200, calculate "UTC": 1100, adjust for timezone: 1400 ---->OK
Using a grabber, which calculates the local time itself:
No DST
file: 1300+0300, calculate UTC: 1000, adjust for timezone: 1300 --->OK
DST
file: 1400+0300, calculate "UTC": 1100, adjust for timezone: 1400 --->OK
Conclusion: Assuming I am right about the subtract 1 hour, your suggested method always works, even if you grab from another country (1700+0700)!
2) Is this actually the way it works?
TIA
Hi
Francis already explained what an xmltv importer should do wrt timezone, dst and xmltv offset. Since you are the author of Xepg I recommend to read article http://webgrabplus.com/content/times-time-zones-and-dst-corrections
Because I suspect that Xepg handles timezones the wrong way (forgive me if I am wrong!) I will explain in depth how it should be done and why .
20151115214500 +0100 must be interpreted as 2015/11/15 21:45 in a zone with an actual timeoffset of 1 hour wrt UTC, so in effect this xmltv time is 20:45 UTC.
This is important because in this way , and by definition, the xmltv times are valid everywhere in the world, independant of local timezones and dst rules!!
(in most cases, the times on the tvguide site are local times with dst rules applied. In that case WG++ has the difficult task to convert the time back to UTC by calculating the actual local UTC offset and the actual dst correction in it. In this case the timeoffset will change if dst changes)
(in some other cases, like in dk.timefor.tv, the times on the site are already in UTC, easy , WG++ applies a constant +0000 timeoffset)
This should do the following:
- Calculate the UTC time by subtracting the xmltv offset.
- Determine the actual local UTC offset from the users computer (that is why it is important the the user has set the computer to the local timezone with dst enabled!!) and correct the UTC time for it.
In simple terms .. xmltvtime - xmltvtimeoffset + actual local UTC offset
a. xmltv :20151115214500 +0100, user in Denmark.
subtract the timeoffset : 2015/11/15 21:45 - 01:00 = 2015/11/15 20:45
add the actual local UTC offset (01:00 in November) 2015/11/15 20:45 + 01:00 = 2015/11/15 21:45
This is the most common situation, the site has its times in local time and the user lives in the same location.
b. xmltv :20151115214500 +0100, user in Canary Islands (like me)
- subtract the timeoffset : 2015/11/15 21:45 - 01:00 = 2015/11/15 20:45 , same as with a of course, xmltv times are 'global'
- add the actual local UTC offset (00:00 in November) 2015/11/15 20:45 + 00:00 = 2015/11/15 20:45
This is correct because if I want to see a show that occurs at 21:45 in Denmark, it is 20:45 here!
This example works for every location in the world!
c. site times in UTC, like with dk.timefor.tv:
xmltv :xmltv :20151115204500 +0000
- subtract the timeoffset : 2015/11/15 20:45 - 00:00 = 2015/11/15 20:45 , same as with a and b of course, xmltv times are 'global'
- rest as a. or b.
I suspect that Xepg only works correct in case a. It assumes that the xmltv timeoffset is also the actual local UTC offset.
I hope that you will correct the Xepg importer if that is needed.
Francis and me always have great difficulty to explain that if WG++ has its times correct the user still find them offset in the epgviewer.
Very recently I had an exchange of confusions with a WG++ user Andreas (I can send you his mail address if yoy want) which uses Xepg. He didn't want to believe that the error was with Xepg
You can also try our own viewer http://www.webgrabplus.com/sites/default/files/downloads/Misc/EPGEdit1.4.zip to demonstrate the effect of the method described above. You can even experiment with the source code if you like.
Jan
P.S. Parts of the discussion with Andreas:
ME: Basically there cannot be a date error anymore because the date is the date of the epg data of the site . The time in UTC is now presented with timeoffset +0000. So in the output xmltv you will see 20152910012000 +0000.
Now how will you get the correct time in your epg viewer. Assuming you live in Denmark , now UTC +01:00 (wintertime) (but in fact it is not essential, because it works in all timezones in the world), and with your computer set to the local timezone, your viewer or your Mediacenter will correct the xmltv time for the timezone of your computer. The xmltv importer of that should take care of that. If it doesn't, its an error of that xmltv importer!!
(Some importers do not handle the timeoffset in the xmltv correctly or ignore them all together). You can check if it performs correctly if there is the time in the epg viewer are one hour later than the one in the xmltv and of course the same date. If it interest you also read http://webgrabplus.com/content/times-time-zones-and-dst-corrections
If you have such a bad behaving xmltv importer you can use http://webgrabplus.com/sites/default/files/download/utility/xmltv_time_correct/xmltv_time_correct.zip to offset the times in the xmltv.
And me again:
Your xmltv is still made with the wrong timezone setting. It must be UTC !! That results in the listing as above, eg 11:50 UTC (20151030115000 +0000) for Hammerslag 2008, which is 12:50 in Danmark. As explained before the conversion from UTC to local time is always done by the xmltv importer. See my example with the xmltv importer of our own viewer. But I can assure you that the xmltv importer for Windows Media Center (e.g. Big Screen EPG) does exactly the same. If yours doesn’t, its wrong!!
And :
Some more explanation. The latest version of dk.timefor.tv.ini gets the times directly from the website, complete, date and time. In that mode (there is also another one, described below) the program doesn’t manipulate or recalculate or shift these times at all! All the times in the xmltv are the ones it got from the website. So if there is an irregularity in the xmltv time then the same irregularity is in the times given by the site! You may react by saying that that can’t be true because there aren’t any irregularities on the front page epg view. But it can because this site lists its times twice, once as the time it uses to display on the front page epg viewer and another as unix time.
This is part of how a show is listed in the website epg data page:
<td class="time"><p>04:10:</p></td>
<td class="title"><p><a href="http://746506.skal.fun/i/120501446952200-mord-centrum" class="programsummary" programid="120501446952200">Mord i centrum</a></p></td>
The first 04:10 is the display time, without a date
The second is the unix time 1446952200 which after conversion is Sun, 08 Nov 2015 03:10:00 GMT
As you will notice the Unix time is in GMT (UTC) and is one hour earlier (which is correct)
What I am saying is that there might be a mistake in one or the other time now and then! It won’t be the first time that such happens.
But there is a second time extraction in WG++. That was used in the previous version of the ini. That used the first time, 04:10, without a date. So WG++ has to add the date . It does that by assuming that the first grabbed show has its starttime ‘today’. Then it must track the time to pass midnight, to add one day to the date. This is a rather tricky procedure which is not fully fault proof.
Thank you very much for this detailed explanation.
I got it: It is the importers responsibility to correct for both timezone and DST. Xepg is currently not doing it right.
Some more work to do before the next release, fortunalely there is some time available before Denmark goes DST.
Thanks for great support.
I have a problem with start and stop time. I run grabber now. Now timestamp is "1511039095000". and it grabs programs with timestamp "20171118062000".
20171118062000 - 1511039095000 = 18660078967000 !!
"18660078967000" more than real timestamp!! How can I fix it to grab correct time?