68 replies to this topic

[Rammy]

De tijds instelling staat reeds op NTP alleen, dus niet op auto.

[WanWizard]

Kan best zijn dat er nog meer bugs in 8.3-release zitten, dat is anderhalf jaar oude code.

 

Die versie is al even end-of-life, daar ga ik geen tijd meer aan besteden, zeker niet omdat het inmiddels al lang is opgelost.

[Rammy]

Ik heb maar weer eens de moeite genomen om over te gaan naar de voorgestelde development versie in de hoop dat deze versie het tijd probleem kan oplossen.

Bij het opnieuw instellen van mijn STB en geven van het commando init 4 in de cmd kreeg ik 2 maal een GSOD (green screen of death) gepresenteerd op mijn tv.

De STB startte niet automatisch na 10 seconden op zoals op het scherm geclaimed werd.

Ik heb jullie het opgestelde crash report bijgevoegd.

Wellicht kunnen jullie hiermee een oorzaak achterhalen.

 

Voor het terugleggen van mijn persoonlijke bouquet gebruik ik altijd de plugin OpenWebif, onder Pli 7.3 en Pli 8.3 werkt dit uitstekend.

Maar zoals ik al reeds eerder bij Openpli 9.0 gemerkt, werkt het restore en backup proces nog steeds niet.

Ik heb dus veel tijd moeten besteden aan het opnieuw aanmaken van mijn persoonlijk bouquet en het verwijderen van de ongewenste bouquetten.

Ik zou het dus erg fijn vinden als de problemen met de OpenWebif plugin opgelost zouden kunnen worden.

Bij wie moet ik deze problemen melden?

 

Ik heb de tijds instelling op auto staan.

Ik zal je nog laten weten of de tijds problemen nu definitief opgelost zijn.

 

[littlesat]

Waarschijnlijk een bekend probleem dat je even je netwerk met de hand mag instelllen….dan zal de tijd dus ook nog niet goed zijn… Maar dat verklaart de gsod nog niet.
De openwebif hoort het gewoon te doen.

Edited by littlesat, 24 July 2024 - 22:29.

[WanWizard]

Ik heb jullie het opgestelde crash report bijgevoegd.

 

Eh... nee.

 

Log bestanden zippen, en dan als bijlage hier plaatsen, via de "more reply options" button.

[WanWizard]

Voor het terugleggen van mijn persoonlijke bouquet gebruik ik altijd de plugin OpenWebif, onder Pli 7.3 en Pli 8.3 werkt dit uitstekend.

Maar zoals ik al reeds eerder bij Openpli 9.0 gemerkt, werkt het restore en backup proces nog steeds niet.

Ik heb dus veel tijd moeten besteden aan het opnieuw aanmaken van mijn persoonlijk bouquet en het verwijderen van de ongewenste bouquetten.

Ik zou het dus erg fijn vinden als de problemen met de OpenWebif plugin opgelost zouden kunnen worden.

 

Ik flash en backup / restore dagelijk meerdere boxen, met allerlei versies, en de web interface, vooral de API daarvan, wordt hier ook zwaar gebruikt. Dus een generiek probleem is dat zeker niet.

 

Waar littlesat op doelt: als je een backup van 8.x restored op 9.0 of develop, en je gebruikt vast ingestelde IP adressen op de box ipv DHCP, dan moet je eenmalig na de restore opnieuw de DNS installen.
Dit is omdat dit mechanisme in Linux is veranderd, en er geen automatisch conflict-vrij migratie pad bestaat. Dit staat vermeld in de release notes van 9.0.

[Rammy]

Nu bij deze dan de gezipte crash_log file.

[Rammy]

 

Voor het terugleggen van mijn persoonlijke bouquet gebruik ik altijd de plugin OpenWebif, onder Pli 7.3 en Pli 8.3 werkt dit uitstekend.

Maar zoals ik al reeds eerder bij Openpli 9.0 gemerkt, werkt het restore en backup proces nog steeds niet.

Ik heb dus veel tijd moeten besteden aan het opnieuw aanmaken van mijn persoonlijk bouquet en het verwijderen van de ongewenste bouquetten.

Ik zou het dus erg fijn vinden als de problemen met de OpenWebif plugin opgelost zouden kunnen worden.

 

Ik flash en backup / restore dagelijk meerdere boxen, met allerlei versies, en de web interface, vooral de API daarvan, wordt hier ook zwaar gebruikt. Dus een generiek probleem is dat zeker niet.

 

Waar littlesat op doelt: als je een backup van 8.x restored op 9.0 of develop, en je gebruikt vast ingestelde IP adressen op de box ipv DHCP, dan moet je eenmalig na de restore opnieuw de DNS installen.
Dit is omdat dit mechanisme in Linux is veranderd, en er geen automatisch conflict-vrij migratie pad bestaat. Dit staat vermeld in de release notes van 9.0.

 

De box staat standaard op DHCP ingesteld en verkrijgt dus zijn IP adres via de router.

Hij krijgt wel een vast IP adres toegewezen door de router op basis van het MAC adres van de box.

Dus volgens jouw verhaal zou dit voldoende moeten zijn om de migratie conflict vrij te laten verlopen.

Helaas is dit niet zo bij mij op dit moment.

 

De OpenWebif plugin kan ik met mijn browser benaderen. Maar het backupen en/of restoren van mijn bouquet werkt helaas niet meer.

Ik kan wel een file kiezen (restore) of ingeven (backup) maar daarna gebeurt er niets meer.

Edited by Rammy, 25 July 2024 - 15:34.

[WanWizard]

Nu bij deze dan de gezipte crash_log file.

 

Nope...

 

Je moet hier op de Browse knop drukken om het bestand te selecteren:

 Screenshot from 2024-07-25 16-34-09.png   21.12KB   1 downloads

 

En daarna moet je op de "Attach This File" knop drukken om het bestand te uploaden en aan de post te hangen.

[WanWizard]

De box staat standaard op DHCP ingesteld en verkrijgt dus zijn IP adres via de router.

 

Hij krijgt wel een vast IP adres toegewezen door de router op basis van het MAC adres van de box.

Dus volgens jouw verhaal zou dit voldoende moeten zijn om de migratie conflict vrij te laten verlopen.

 

Nee, dat schreef ik niet . Dan heb je geen last van het DNS probleem na migratie. Wat voor ellende je nog meer hebt, daar doe ik zonder logs geen uitspraak over...

 

De OpenWebif plugin kan ik met mijn browser benaderen. Maar het backupen en/of restoren van mijn bouquet werkt helaas niet meer.

Ik kan wel een file kiezen (restore) of ingeven (backup) maar daarna gebeurt er niets meer.

 

Dat werkt hier prima, zelfs op een develop of een scarthgap test image, weet je zeker dat je browser niks blokkeert? Het zal de eerste keer niet zijn.

[Rammy]

 

De box staat standaard op DHCP ingesteld en verkrijgt dus zijn IP adres via de router.

 

Hij krijgt wel een vast IP adres toegewezen door de router op basis van het MAC adres van de box.

Dus volgens jouw verhaal zou dit voldoende moeten zijn om de migratie conflict vrij te laten verlopen.

 

Nee, dat schreef ik niet . Dan heb je geen last van het DNS probleem na migratie. Wat voor ellende je nog meer hebt, daar doe ik zonder logs geen uitspraak over...

 

De OpenWebif plugin kan ik met mijn browser benaderen. Maar het backupen en/of restoren van mijn bouquet werkt helaas niet meer.

Ik kan wel een file kiezen (restore) of ingeven (backup) maar daarna gebeurt er niets meer.

 

Dat werkt hier prima, zelfs op een develop of een scarthgap test image, weet je zeker dat je browser niks blokkeert? Het zal de eerste keer niet zijn.

 

Welke logs heb je nodig om een zinnige uitspraak hierover te kunnen doen?

 

Voor zover ik zie heb ik niets geblokkeerd in de browser voor dit tab-blad.

No-script staat alles toe.

uBlock Origin blokt ook niets.

 

Indien ik iets in de EPG wil opzoeken via de OpenWebif plugin dan krijg ik een foutmelding met de tekst 'error! Loading Page' gepresenteerd.

Onder 8.3 werkte dit ook gewoon.

 

Als ik een backup wil maken van mijn bouquet dan ga ik naar de bouquet editor in de OpenWebif plugin en klik op de export knop,, na ingave van een naam of akkoord gaande met de gepresenteerde naam en gevolg door een return  dan zou er in '/var/volatile/tmp' directory van de box een file moeten verschijnen met de naam 'bouquets_backup'.

Helaas zie ik dit ook niet gebeuren, onder 8.3 werkte ook dit feilloos.

 

Ik kan ook de EPG gewoon benaderen en opname timers aanmaken.

 

Zou het iets met file rechten te maken kunnen hebben, niet dat ik deze gewijzigd heb, je weet maar nooit.

Edited by Rammy, 25 July 2024 - 17:22.

[Rammy]

Dan nogmaals een poging voor de crash file.

Attached Files

•  Devellopment.zip   8.94KB   1 downloads

[Rammy]

Naar het lijkt is het klok probleem opgelost althans het is terug gebracht geworden tot circa 1.2 seconden.

Is dit zo normaal of zou de klok offset nadat het NTP gebeuren weer online is niet na de tweede sync weer in de 0.00.. moeten zitten.

 

 

root@vu+:~# grep ntpdate /var/log/messages
Jul 24 20:34:26 vu+ daemon.notice ntpdate[1353]: step time server 45.138.55.62 offset +1721846026.373159 sec
Jul 24 21:30:00 vu+ cron.info crond[1400]: USER root pid 1948 cmd /usr/bin/ntpdate-sync silent
Jul 24 21:30:07 vu+ daemon.notice ntpdate[1957]: adjust time server 45.138.55.60 offset +0.031361 sec
Jul 24 22:30:00 vu+ cron.info crond[1400]: USER root pid 2029 cmd /usr/bin/ntpdate-sync silent
Jul 24 22:30:07 vu+ daemon.notice ntpdate[2038]: adjust time server 213.136.0.252 offset +0.019241 sec
Jul 24 23:30:00 vu+ cron.info crond[1400]: USER root pid 2053 cmd /usr/bin/ntpdate-sync silent
Jul 24 23:30:07 vu+ daemon.notice ntpdate[2062]: adjust time server 94.198.159.11 offset +0.025160 sec
Jul 25 00:30:00 vu+ cron.info crond[1400]: USER root pid 2088 cmd /usr/bin/ntpdate-sync silent
Jul 25 00:30:07 vu+ daemon.notice ntpdate[2097]: adjust time server 81.172.225.142 offset +0.364890 sec
Jul 25 01:30:00 vu+ cron.info crond[1400]: USER root pid 2112 cmd /usr/bin/ntpdate-sync silent
Jul 25 01:30:16 vu+ daemon.err ntpdate[2121]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 02:30:00 vu+ cron.info crond[1400]: USER root pid 2134 cmd /usr/bin/ntpdate-sync silent
Jul 25 02:30:12 vu+ daemon.err ntpdate[2143]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 03:30:00 vu+ cron.info crond[1400]: USER root pid 2157 cmd /usr/bin/ntpdate-sync silent
Jul 25 03:30:12 vu+ daemon.err ntpdate[2166]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 04:30:00 vu+ cron.info crond[1400]: USER root pid 2183 cmd /usr/bin/ntpdate-sync silent
Jul 25 04:30:12 vu+ daemon.err ntpdate[2192]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 05:30:00 vu+ cron.info crond[1400]: USER root pid 2207 cmd /usr/bin/ntpdate-sync silent
Jul 25 05:30:12 vu+ daemon.err ntpdate[2216]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 06:30:00 vu+ cron.info crond[1400]: USER root pid 2232 cmd /usr/bin/ntpdate-sync silent
Jul 25 06:30:12 vu+ daemon.err ntpdate[2241]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 07:30:00 vu+ cron.info crond[1400]: USER root pid 2254 cmd /usr/bin/ntpdate-sync silent
Jul 25 07:30:12 vu+ daemon.err ntpdate[2263]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 08:30:00 vu+ cron.info crond[1400]: USER root pid 2276 cmd /usr/bin/ntpdate-sync silent
Jul 25 08:30:12 vu+ daemon.err ntpdate[2285]: name server cannot be used: Temporary failure in name resolution (-3)
Jul 25 09:30:00 vu+ cron.info crond[1400]: USER root pid 2297 cmd /usr/bin/ntpdate-sync silent
Jul 25 09:30:09 vu+ daemon.notice ntpdate[2306]: step time server 185.51.192.62 offset +2.241020 sec
Jul 25 10:30:00 vu+ cron.info crond[1400]: USER root pid 2315 cmd /usr/bin/ntpdate-sync silent
Jul 25 10:30:08 vu+ daemon.notice ntpdate[2324]: step time server 45.138.55.62 offset +1.272528 sec
Jul 25 11:30:00 vu+ cron.info crond[1400]: USER root pid 2333 cmd /usr/bin/ntpdate-sync silent
Jul 25 11:30:08 vu+ daemon.notice ntpdate[2342]: step time server 45.138.55.60 offset +1.274627 sec
Jul 25 12:30:00 vu+ cron.info crond[1400]: USER root pid 2353 cmd /usr/bin/ntpdate-sync silent
Jul 25 12:30:08 vu+ daemon.notice ntpdate[2362]: step time server 45.83.205.227 offset +1.275824 sec
Jul 25 13:30:00 vu+ cron.info crond[1400]: USER root pid 2372 cmd /usr/bin/ntpdate-sync silent
Jul 25 13:30:08 vu+ daemon.notice ntpdate[2381]: step time server 45.138.55.61 offset +1.273830 sec
Jul 25 14:30:00 vu+ cron.info crond[1400]: USER root pid 2392 cmd /usr/bin/ntpdate-sync silent
Jul 25 14:30:08 vu+ daemon.notice ntpdate[2401]: step time server 81.172.225.142 offset +1.271131 sec
Jul 25 15:30:00 vu+ cron.info crond[1400]: USER root pid 2412 cmd /usr/bin/ntpdate-sync silent
Jul 25 15:30:08 vu+ daemon.notice ntpdate[2421]: step time server 45.83.205.227 offset +1.272606 sec
Jul 25 16:30:00 vu+ cron.info crond[1400]: USER root pid 2452 cmd /usr/bin/ntpdate-sync silent
Jul 25 16:30:09 vu+ daemon.notice ntpdate[2461]: step time server 185.51.192.62 offset +1.271660 sec
Jul 25 17:30:00 vu+ cron.info crond[1400]: USER root pid 2472 cmd /usr/bin/ntpdate-sync silent
Jul 25 17:30:08 vu+ daemon.notice ntpdate[2481]: step time server 167.99.42.106 offset +1.241898 sec
Jul 25 18:30:00 vu+ cron.info crond[1400]: USER root pid 2500 cmd /usr/bin/ntpdate-sync silent
Jul 25 18:30:08 vu+ daemon.notice ntpdate[2509]: step time server 213.136.0.252 offset +1.250869 sec

[WanWizard]

Er staat iets in je bouquetten of de bestandsnamen van je bouqetten, wat niet deugd, bv wat geen valide utf-8 is. Bijvoorbeeld iets met accenten dat op een Windows machine gemaakt is.

 

Dat was tot 8.3 minder een probleem, want die draait op Pyhton 2, en die vind alles bytes. Maar 9.0 en nieuwer draait op Python 3, en daar is het wel degelijk van belang.

 

De box crasht in de C code, wat het moeilijk maakt om precies te achterhalen waar het fout gaat.

 

Maar de oorzaak is dus jou bouquetten, niet de Image.

[WanWizard]

En t.a.v. de klok: geen enkele STB heeft realtime clock hardware aan boord, de clock wordt geemuleerd in software en met rudimentaire timing hardware.

 

Dus 2 seconden per uur is helemaal niet zo vreemd, aan de hoge kant, maar niet vreemd. Mijn Duo 4K schommelt tussen 0.6 en 1.6,

 

De mainboards met een HiSilicon chipset lijken beter ontworpen te zijn, die zitten bij mij allemaal onder de 0.1 seconde per uur.

[Rammy]

Er staat iets in je bouquetten of de bestandsnamen van je bouqetten, wat niet deugd, bv wat geen valide utf-8 is. Bijvoorbeeld iets met accenten dat op een Windows machine gemaakt is.

 

Dat was tot 8.3 minder een probleem, want die draait op Pyhton 2, en die vind alles bytes. Maar 9.0 en nieuwer draait op Python 3, en daar is het wel degelijk van belang.

 

De box crasht in de C code, wat het moeilijk maakt om precies te achterhalen waar het fout gaat.

 

Maar de oorzaak is dus jou bouquetten, niet de Image.

Even voor alle duidelijkheid ik heb alle bouquetten van de hans lijst gekregen zowel bij 8.3 als bij de devellopment versie.

Ikzelf heb geen bestanden aangemaakt en zeker niet onder Windows.

Ik gebruik uitsluitend Linux.

Ik heb alleen zenders vanuit de zenderlijst in mijn eigen zenderlijst geplaatst en zo een eigen bouquet aangemaakt.

 

Hebben jullie software welke de 'backup_bouquet' file gemaakt door 8.3 kan scannen op probleem characters voor Python3.

 

Zou het een oplossing kunnen zijn dan maar alle bouquetten te verwijderen en vanuit de zenderlijst nieuwe bouquetten aan te maken.

Of kan ik dan beter de box opnieuw flashen en geen hans zenderlijst meer laten installeren maar deze dan zelf samen te stellen vanuit de door de box gescande satellieten.
 

[WanWizard]

In principe moet er niks mis zijn met de hans lijst, hele volksstammen gebruiken die lijsten. Ik zou dan ook niet direct weten wat daar mis aan zou moeten zijn.

 

Kan ook best zijn dat er nog ergens in die OWIF bouquet editor nog iets zit dan niet (goed) is geconverteerd van Python 2 naar Python 3. Je bent de eerste die ik tegen kom die dat gebruikt, de meeste mensen gebruiken een PC tool.

 

Probleem ( of uitdaging, afhankelijk van hoe je er naar kijkt ) is dat de huidige OWIF end of life is, en niet meer onderhouden wordt. Het staat nog op mijn to do list om daar wat aan te doen (zal voor 9.1-release zijn).

[Rammy]

In principe moet er niks mis zijn met de hans lijst, hele volksstammen gebruiken die lijsten. Ik zou dan ook niet direct weten wat daar mis aan zou moeten zijn.

 

Kan ook best zijn dat er nog ergens in die OWIF bouquet editor nog iets zit dan niet (goed) is geconverteerd van Python 2 naar Python 3. Je bent de eerste die ik tegen kom die dat gebruikt, de meeste mensen gebruiken een PC tool.

 

Probleem ( of uitdaging, afhankelijk van hoe je er naar kijkt ) is dat de huidige OWIF end of life is, en niet meer onderhouden wordt. Het staat nog op mijn to do list om daar wat aan te doen (zal voor 9.1-release zijn).

Ik heb in mijn bouquets 4 streams gevonden die characters bevatten die niet UTF-8 valide zijn, te weten:

 

- 'userbouquet.stream_italii_.radio', op positie 33105 als eerste positie

- 'userbouquet.stream_jazz_radio.radio', op positie 7867 als eerste positie

- 'userbouquet.stream_muziek.tv', op positie 49567 als eerste positie

- 'userbouquet.stream_webcams_buitenland.tv', op positie 44786 als eerste positie

 

Nu vraag ik me af kan ik deze file's zomaar verwijderen uit de 'enigma2' directory of worden deze file's ook nog elders ge-administreerd.

[Rammy]

 

In principe moet er niks mis zijn met de hans lijst, hele volksstammen gebruiken die lijsten. Ik zou dan ook niet direct weten wat daar mis aan zou moeten zijn.

 

Kan ook best zijn dat er nog ergens in die OWIF bouquet editor nog iets zit dan niet (goed) is geconverteerd van Python 2 naar Python 3. Je bent de eerste die ik tegen kom die dat gebruikt, de meeste mensen gebruiken een PC tool.

 

Probleem ( of uitdaging, afhankelijk van hoe je er naar kijkt ) is dat de huidige OWIF end of life is, en niet meer onderhouden wordt. Het staat nog op mijn to do list om daar wat aan te doen (zal voor 9.1-release zijn).

Ik heb in mijn bouquets 4 streams gevonden die characters bevatten die niet UTF-8 valide zijn, te weten:

 

- 'userbouquet.stream_italii_.radio', op positie 33105 als eerste positie

- 'userbouquet.stream_jazz_radio.radio', op positie 7867 als eerste positie

- 'userbouquet.stream_muziek.tv', op positie 49567 als eerste positie

- 'userbouquet.stream_webcams_buitenland.tv', op positie 44786 als eerste positie

 

Nu vraag ik me af kan ik deze file's zomaar verwijderen uit de 'enigma2' directory of worden deze file's ook nog elders ge-administreerd.

 

Ik heb de bovengenoemde streams uit mijn bouquet verwijderd en ziedaar het exporteren lukt nu weer.

Er word ge-exporteerd naar de Downloads directory op de computer dus niet de box.

Er zitten dus blijkbaar toch fouten in de lijst van hans, niet alle userbouquet.stream bestanden zijn UTF-8 valide.

 

Nu werkt ook het opzoeken in de EPG weer.

Voor mij is het een raadsel wat hiervan de oorzaak is.

Edited by Rammy, 25 July 2024 - 21:25.

[littlesat]

userbouquet.stream bestanden zijn UTF-8 valide.
->
Klopt…