OpenViX 6.8 Release discussion thread

[Huevos]

So on the server box, add /etc/epgimport/epgexport.sources.xml. Delete the epg and disable OpenTV and freesat so it is not imported again. Use EpgImporter on the server box to import from itself. Check if the entries are correct.

 

[smipx]

So on the server box, add /etc/epgimport/epgexport.sources.xml. Delete the epg and disable OpenTV and freesat so it is not imported again. Use EpgImporter on the server box to import from itself. Check if the entries are correct.

OK. Will try at some point next week. I need to wait till there is a bit of downtime as the boxes are used by the family. I'll report findings back.

 

[Glenn2]

Hi - gbue4k user here....
On my box I have some videos in webm and mkv formats. The webm ones do not allow skipping at all, they just jump back to the start when you try to jump forward or back.
The mkv ones do allow skipping but go very pixelated for a few seconds when you do so.
Does anyone else have these problems? I can get around it by selecting 'play with exteplayer3/gstplayer' via the menu button, but default playback is bad.

I've only just arrived from 6.7 so I can't comment on previous versions of 6.8, but 6.7 did not do this. To verify I flashed 6.7 back into another slot and all is fine (although I can't get wireguard to work on 6.7 or else I would just stay on it).

 

[smipx]

OK. Will try at some point next week. I need to wait till there is a bit of downtime as the boxes are used by the family. I'll report findings back.

Hi @Huevos , Did the test and guess what. The programs are being imported an hour late on the server box too. I kept an eye on 1 program and it was there at 10pm, then I cleared it, did an epg importer and it was then there an hour later than it should have been. Does this mean that the epg-importer plugin is doing something odd? My time settings are pretty normal. The time is correct on the server as far as I can see:



I can only think that the EPG-Importer plugin is not taking acount of British Summertime or someting odd like that.
Very strange!!

I have since cleared it all down and run EPGRefresh on the Server box (tuning to a few Satellite channels and a few Tererestrial channels and the EPG is now back to normal with the programs at the correct times.

For now, I have set my slave box back to look directly at the EPG on the server box (via the NFS share) and the EPG on the slave box is now also correct.
Back to my original question of why this is not a good idea? It seems to work well and the programs have the correct times in the schedule too. Happy to go down the Export/import route if this issue with the incorrect time can be bottomed out.

Thanks
Paul

 

[Huevos]

What does "look at the epg on the server box" mean? If it means EPG.DAT that could be very stale as it is only written at reboot or it forced.

 

[smipx]

What does "look at the epg on the server box" mean? If it means EPG.DAT that could be very stale as it is only written at reboot or it forced.

I have the server box do an epg refresh every few hours (as it's always on standby and I want it to pick up any late program changes). In addition it is set to save the epg data to epg.dat every hour.

The client box is set to load the epg data from the server box every two hours also.

 

[smipx]

Hi @Huevos , Did the test and guess what. The programs are being imported an hour late on the server box too. I kept an eye on 1 program and it was there at 10pm, then I cleared it, did an epg importer and it was then there an hour later than it should have been. Does this mean that the epg-importer plugin is doing something odd? My time settings are pretty normal. The time is correct on the server as far as I can see:

View attachment 68806

I can only think that the EPG-Importer plugin is not taking acount of British Summertime or someting odd like that.
Very strange!!

I have since cleared it all down and run EPGRefresh on the Server box (tuning to a few Satellite channels and a few Tererestrial channels and the EPG is now back to normal with the programs at the correct times.

For now, I have set my slave box back to look directly at the EPG on the server box (via the NFS share) and the EPG on the slave box is now also correct.
Back to my original question of why this is not a good idea? It seems to work well and the programs have the correct times in the schedule too. Happy to go down the Export/import route if this issue with the incorrect time can be bottomed out.

Thanks
Paul

So... more research. Conclusion: Rytec data already has a compensation for BST (so all programs are in the rytec data at starting an hour earlier than they actually start). When you export the EPG locally (to import somewhere else) it takes the time in the EPG and does not adjust it to compensate for BST. The EPG-Importer software does not handle this and this is why the rytec data is "tweaked" at source. The EPG Exporter does not do this tweak so EPG-Importer gets the times wrong.

This is the data when compared:

Rytec data is obviously adjusted in the knowlege that enigma2 does not handle BST or any other summertime offset upon importation of EPG data and has to be fed the wrong data to compensate. EPG-Exporter needs to also take this into account and massage its export to compensate.

 

[Huevos]

Can you try an updated version of the epgexport plugin?

Send to the epgexport plugin folder and then restart. Afterwards recreate the xml files using the epgexport plugin.

 

[smipx]

Can you try an updated version of the epgexport plugin?

Send to the epgexport plugin folder and then restart. Afterwards recreate the xml files using the epgexport plugin.

Sure. Will give it a go tonight after everyone has gone to bed

 

[birdman]

Rytec data is obviously adjusted in the knowlege that enigma2 does not handle BST or any other summertime offset upon importation of EPG data and has to be fed the wrong data to compensate.

On Linux (Unix) systems all clocks run on UTC.
It is the display/handling of the clock that adds any timezone offsets.
This allows different processes on the same system to run in different timezones - juts by setting the timezone that they wish to be on.

The EPG and timer data in Enigma2 is all in UTC.

 

[smipx]

Sure. Will give it a go tonight after everyone has gone to bed

Hi. I copied the new py and rebooted but getting a constant enigma2 crash. Crash file attached:

 

[smipx]

Hi. I copied the new py and rebooted but getting a constant enigma2 crash. Crash file attached:

reverted to old pyc for now (luckily I renamed it pyc.old before updating) and it boots again okay.

 

[Huevos]

That crash is nothing to do with my change. I will have to investigate.

 

[smipx]

That crash is nothing to do with my change. I will have to investigate.

OK.

 

[Huevos]

I fixed the crash. Not related to my code. Try the offset now.

 

[smipx]

I fixed the crash. Not related to my code. Try the offset now.

Hi, Machine booted fine this time. Went through export with yelow key and it creashed a few moments later. Thanks, Paul

Crash log attached.

Seems to be the line:
09:09:38.1162 File "/usr/lib/enigma2/python/Plugins/Extensions/EPGExport/plugin.py", line 800, in getTimezoneOffset
total_minutes = int(offset / timedelta(minutes=1))
^^^^^^^^^
09:09:38.1164 NameError: name 'timedelta' is not defined
09:09:38.1167 [ePyObject] (CallObject(<bound method ActionMap.action of <Components.ActionMap.ActionMap object at 0xb00e9f10>>,('ColorActions', 'yellow')) failed)


dmesg

 

[Huevos]

Ok, try again.

 

[smipx]

Ok, try again.

So it ran this time and produced the export file. I can see that the exporter items have +01000

</programme>
<programme start="20260519121500 +0100" stop="20260519130000 +0100" channel="BBC ONE SW HD (T)">
<title lang="en">Bargain Hunt</title>
<sub-title lang="en">Natasha Raskin Sharp and the teams head to Mid Wales with experts Ben Cooper and Kate Bliss. Natasha also learns about the history of carpet-making. [S,AD] [HD]</sub-title>
</programme>
<programme start="20260519130000 +0100" stop="20260519140000 +0100" channel="BBC ONE SW HD (T)">
<title lang="en">BBC News at One including...</title>
<sub-title lang="en">...Spotlight. The latest national and international news from the BBC. [HD]</sub-title>
</programme>

This is the EPG before I then cleared it ready to test importer:


Put box onto an IP channel so it could not grab any EPG data for satellite
Cleared down EPG ready for import test
Did a restart gui
Confirmed EPG was empty:


I then did the EPG Importer on the exported EPG file.

This is the EPG after the import:



I would say that was a success. The news was imported at 1pm BST and is correct.
I have also configured the "Slave" box to import this using EPG importer and have set it so it saves a local EPG file rather than poiting to the server box.

Many thanks for making that work @Huevos.

Final Question: Why is this better to do this rather than pointing the client box to the NFS share of the Server box's epg.dat file. I never did get to the bottom of that question. This is now clearly going to work but so does the pointing to remote EPG and I just want to be clear as to why one option is better than the other. The NFS pointing option seems simpler with less steps and therefore less chance of something not working???

Regards
Paul

 

[Huevos]

In your case maybe reading EPG.DAT directly across the network works fine.

Also possible if reading across the network is use the path, rather than http path, in epgexport.sources.xml.

 

[smipx]

In your case maybe reading EPG.DAT directly across the network works fine.

Also possible if reading across the network is use the path, rather than http path, in epgexport.sources.xml.

What I'll do is leave it using the Export / import now as that is setup and working after all of your efforts but.... if it glitches its good to know that I can swap back over to my old method also.

At least the EPGExport has been fixed so that it handles daylight savings properly for anyone else who might use it (although I have a sneaking suspicion it may not be many who use it for enigma2 to enigma2 export/import) and so I guess other folk (who perhaps use it for enigma2 to Tivo / plex / Something else) may already have a correction in place at the destination end. Wait now for all the folk complaining that all of their imports into other systems being an hour out by fixing it for enigma2 to enigma2