47 replies to this topic

[robadouche]

[eDVBPESReader] ERROR reading PES (fd=47): Value too large for defined data type

 

Dit is geen errror maar een warning.

 

Grappig dat een warning ERROR heet . Ik zie deze "warnings" eigenlijk alleen tijdens een spinner. Als ik het goed begrijp wordt deze warning dus door het onderliggende probleem veroorzaakt en niet andersom? Als hij hangt loopt blijkbaar de buffer over?

 

Gisteren trouwens een opgenomen film en een aflevering van Lillyhammer teruggekeken. En geen enkele spinner. Ik heb gisteren ook 6.1 RC geflashed. Toeval? 

[WanWizard]

De details zijn niet aan mij besteed, daar heb je een specialist voor nodig. Ik kan alleen de code lezen, en daar zie ik dat de lengte van de ontvangen data wordt opgevraagd, en als dat groter is dan 16384 (de size van de string buffer), dan wordt de data niet opgevraagd, maar wordt deze melding gegeven en wordt de data dus weggegooid.

 

Als ik de specs zo bekijk (https://en.wikipedia...ementary_stream) dan is zo'n pakket van variabele lengte. Ik kan me best voorstellen dat afhankelijk van welke data er is weggegooid er een stabiliteitsprobleem zou kunnen ontstaan.

 

6.1-rc heeft nieuwere drivers voor de VU+ boxen, dan zou ook nog kunnen meespelen, de 6.0 drivers hadden bugs bij het afspelen (vooral in combinatie met spoelen) van een opname.

[Erik Slagter]

Ik geloof niet dat die size sowieso groter dan 16k mag zijn. Dus dat enigma 'm weggooit is terecht. Let wel: dit is geen video of audio stream, die worden buiten enigma om door de hardware geleidt.

 

Waar je waarschijnlijk tegenaanloopt is dat er hier en daar stukje stream corrupt is. Dat kan komen door:

- uncorrectable errors in de ontvangst

- halverwege in een stream "er in vallen", je zult ze waarschijnlijk meestal helemaal aan het begin van een opname zien voorbijkomen

 

Beide zijn geen probleem.

[Erik Slagter]

Ik heb even de code erbij gepakt. De foutmelding is misleidend. De melding "[eDVBPESReader] ERROR reading PES" komt van enigma, de melding "Value too large for defined data type" is een systeemerror, de string die hoort  bij EOVERFLOW en komt terug uit de read() call. Het mooiste is dat volgens de API read() helemaal geen EOVERFLOW zou mogen teruggeven, dus dat is iets raars aan de driver, een "driver quirk". Kennelijk geeft het geen foutconditie aan, want ik zie 'm zeer regelmatig.

 

Ik neig ernaar om deze foutmelding voor deze systeemerror te onderdrukken, maar misschien dat er toch een relatie is met driverproblemen. Daarom een "opdrachtje" aan degene die het probleem meldt: enigma in de voorgrond draaien met debug info aan en dan kijken of de melding ook optreedt als er geen problemen zijn.

[robadouche]

Even 2 antwoorden:

 

1. De test heb ik al gedaan. Ik zie de foutmelding alleen in combinatie met een bevriezend beeld. Geen probleem is geen foutmelding.
2. Ik heb nog even iets beter gekeken naar wat er fout gaat. Het gaat ook met RC6.1 niet altijd goed, hoewel de fout wel aanzienlijk minder frequent voorkomt. Ik beperk me even tot afspelen van een opname. Op zeker moment bevriest het beeld voor enkele seconden tot enkele minuten icm bovengenoemde foutmelding. Als ik niets doe, gaat na die tijd het afspelen gewoon door. Lopende opnames worden niet verstoord. Als ik tijdens zo'n bevriezing op de toetsen van de afstandbediening druk, dan kan ik best nog het een en ander, bijv menu, info of teletekst. Zodra ik probeer voor- of achteruit te spoelen (met de cijfertoetsen uiteraard) dan verschijnt pas op dat moment de spinner. Het lijkt er dus op dat niet enigma hangt, maar de onderliggende stroom. Klopt deze laatste bewering?

[WanWizard]

Dat suggereert toch een bug in de drivers, die na het spoelen het spoor bijster raken...

[Erik Slagter]

Graag nog even de output van dmesg op dat moment, de laatste 20 regels (geen boekwerk van 2000 regels graag). En inderdaad, het is intussen wel zeker dat het een driver issue is.

[robadouche]

Hoi,

 

Probleem is opgelost, zo lijkt het. Mijn NAS (Synology) gaf af en toe op 1 vd 2 schijven een I/O read error. Af en toe is ongeveer 1x per week. Dat wist ik ook al een tijdje, maar ik had er geen last van,dus geen haast om op te lossen. Alles leek goed door te lopen. Ik ging er van uit dat de NAS dan gewoon de data van de goede wel werkende schijf af pakt. Maar de afgelopen week nam de frequentie van de melding toe en heb ik besloten de 2e schijf te vervangen. Sinds die tijd geen enkele spinner meer gehad, Niet bij afspelen opnames, niet bij zappen en niet bij door de lijst met zenders scrollen. De faulty disk was blijkbaar toch de oorzaak van dit probleem. Kennelijk zijn enigma of de drivers gevoelig voor timeouts bij het lezen van (netwerk)schijven en komen die timeouts bij normaal gebruik niet of nauwelijks voor?

 

@Erik, als de situatie zo blijft kan ik geen dmesg output meer aanleveren. Maar er staat nog in 1 van mijn vorige posts. Het stukje wat daarvan relevant lijkt is:

[VID]: VIDEO_CONTINUE -8  1
[AUD]: AUDIO_CONTINUE -8 1 aph=0xcf31f080
[AUD]: Mute : 0
[AUD]: AUDIO_CHANNEL_SELECT 0
[VID]: VIDEO_STOP 1  1
[AUD]: AUDIO_STOP -8
[AUD]: AUDIO_CONTINUE -8 0 aph=0x0
[AUD]: AUDIO_CONTINUE aph=0 0 0
[LCD]: unknown cmd 0x1015
UBI error: ubi_open_volume: cannot open device 0, volume 0, error -16
[LCD]: unknown cmd 0x1015
UBI error: ubi_open_volume: cannot open device 0, volume 0, error -16
[AUD]: HDMI Max Audio PCM Channels=8
[AUD]: AUDIO_SET_MUTE 0
[AUD]: AUDIO_SET_MIXER -964510224
[AUD]: AUDIO_SET_MIXER : amixl 0, amixr 0
[AUD]: AUDIO_SET_MIXER : next left volume -70, right volume -70
[AUD]: AUDIO_SET_MIXER : next left volume -70, right volume -70
[AUD]: AUDIO_SET_MIXER -964510224
[AUD]: AUDIO_SET_MIXER : amixl 0, amixr 0

Dat gaat dan alleen weer niet over de Nas, maar over het interne flash-geheugen, neem ik aan?

 

@Wanwizard, je had gelijk:

 

 

Dat kan van alles als oorzaak hebben, van corrupte media, trage media, slecht of traag netwerk, server of NAS die traag reageert, een plugin die zich niet gedraagd, etc.

 

Nas die traag reageert, blijkbaar. Ik voelde me een beetje op mijn teentjes getrapt door "slecht netwerk"

[Erik Slagter]

Dat zijn volgens mij geen echte errors.

 

Ik denk dat je geen speciale RAID-disks in je NAS hebt. Non-RAID disks gaan het minutenlang blijven proberen bij een leesfout, dat is eigenlijk wat je juist niet wilt in een RAID opstelling. En zodra de eerste leesfout komt, METEEN de disk vervangen natuurlijk!

[WanWizard]

Dat is wel funest. Bij de playback van een opname moet de SoC is stabiele feed aan data hebben, daar zit weinig of geen buffering in.

 

Dus als het ineens "minutenlang" duurt voordat je data wordt aangeleverd, daar knapt het beeld niet van op.

[robadouche]

Ik heb uiteraard wel een raid-systeem, en volledig redundant. Daarom maakte ik me ook niet veel zorgen om een leesfout per week. Maar... na 2 dagen zonder problemen was de spinner gewoon weer terug. Bij gelegenheid zal ik weer een dmesg maken, maar misschien hebben jullie wel wat aan de output hierboven. Anders houd ik het toch op een hardwareprobleem en moet ik aan een nieuwe.

 

Rob

[robadouche]

Ik heb iets gevonden! De tijdstippen corresponderen met "hangen". Misschien is het de netwerk switch. Ik heb een 24poorts gigabit switch staan. Vervangen is duur, dus eerst maar even testen met kleine switch ertussen. Als de link down blijft gaan, dan ligt het aan de netwerkkaart van de VU, als de verbinding blijft, maar toch af en toe hangt, ligt het aan de switch. Ik houd jullie op de hoogte!

root@vusolo2:~# grep bcmg /var/log/messages
Dec 23 20:10:30 vusolo2 user.info kernel: bcmgenet: configuring instance #0 for external RGMII
Dec 23 20:10:30 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:13:58 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:14:02 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:14:11 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:14:18 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:15:30 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:15:33 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:16:50 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:16:54 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:16:59 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:03 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:17:10 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:14 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:17:16 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:19 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:17:20 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:27 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:17:36 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:40 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:17:44 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:17:48 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:18:06 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:18:10 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:18:11 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:18:14 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 20:18:15 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 20:18:18 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 21:09:04 vusolo2 user.warn kernel: [<803e86dc>] bcmgenet_poll+0x2e4/0x45c
Dec 23 21:30:28 vusolo2 user.warn kernel: [<803e86dc>] bcmgenet_poll+0x2e4/0x45c
Dec 23 21:32:32 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 21:32:35 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 21:32:43 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 21:32:46 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex
Dec 23 21:32:49 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link down
Dec 23 21:32:52 vusolo2 user.info kernel: bcmgenet bcmgenet.0 eth0: link up, 1000 Mbps, full duplex

[robadouche]

Ik heb als test mijn Fritz!box als switch ingezet. Zowel de Vusolo als de Nas. Dat ging even goed. Na 5 minuten schakelde de fritz de snelheid van de vusolo terug nan 1000 naar 100. Daarna geen netwerkverstoringen meer. Het lijkt er dus op de dat de vusolo een instabiel netwerkinterface heeft.Toch hardware dus. Nu wil ik de snelheid van de vu vast zetten op 100 (snel genoeg, toch?) maar hoe moet dat? Ik zie dat nergens als optie. Ik kan /etc/network/interfaces aanpassen, maar dat wordt afgeraden, omdat enigma dat bestand onderhoudt. Ideeën?

[WanWizard]

Kan ook nog de kabel zijn...

[robadouche]

Nee, want die had ik al 2x vervangen, net als de netwerkoutlet in de muur. Weet je hoe ik de snelheid omlaag kan krijgen?

[WanWizard]

Je kunt /etc/network/interfaces wel aanpassen, je moet dan alleen daarna van de netwerk settings in Enigma afblijven.

 

Alternatief, installeer ethtool:

opkg install ethtool

Je kunt daarna de snelheid op deze manier aanpassen (bijvoorbeeld):

ethtool -s eth0 speed 100 duplex full autoneg on

Als dat naar behoren werkt, geef dan maar een gil, dan gaan we verder over hoe je dit er permanent in zet...

[robadouche]

Hoi Wanwizard, dank voor je antwoord. Done! Ik heb /etc/network/interfaces al aangepast. Dus het is al permanent. Ik kan het altijd nog weer weghalen.

 

Vraag: Als ik opnieuw flash wordt /etc/network/interfaces dan aangepast of blijft die in de huidige staat als ik de oude settings weer terugzet?

 

Ik denk dat ik het lek nu wel boven heb. Als ik het netwerk op 1000 zet, gaat het meteen weer mis. Op 100 gaat het goed.

 

Achteraf kan ik het gedrag wel verklaren. Het netwerk stond te klapperen en regelde meestal weer in op 1000, en bleef dus instabiel. Soms echter kwam hij terug als 100. Dan was het netwerk aanzienlijk stabieler en bleef het probleem dus een tijdje weg. Ook op 100 is het netwerk niet helemaal stabiel. Afgelopen nacht iss eth0 1x herstart, zag ik in de log. Omdat ik de Fritz.box op 100 had ingesteld, bleef hij nu wel gewoon op 100. Maar voorheen op de 24-poorts-switch schakelde hij dan gewoon weer naar 1000 en werd weer instabiel. Stom dat ik dit niet eerder heb gezien. Ik was teveel gefocused op de logs van enigma. Bovendien stond dit klapperen (gek genoeg) niet in de dmesg die ik eerder eens uitgebreid had bekeken, zie mijn eerdere post in dit topic.

[WanWizard]

Menu - Plugins - Autobackup - Menu - 1, en ff kijken of je 'm mee backupt.

 

Ik denk dat dit default niet zo is, dus dan moet je 'm even selecteren.

[robadouche]

Dank je wel! Hij stond standaard al aangevinkt, zag ik. Dank voor alle support zover! En nu duimen, dat het nog lang goed blijft gaan. Voor de rest werkt het allemaal geweldig.

[robadouche]

Zelfde fout weer, na amper 2 maanden en nu met interface op 100Mbit. Verder terugschroeven naar 10Mbit verhielp het probleem weer, maar dat is natuurlijk geen oplossing. Dan kan ik niet meer tegelijk opnemen en kijken. Ik ben klaar met vu+. Na eerst een vuduo met rode led probleem (3 keer condensator vervangen) en nu binnen 2,5 jaar een kapotte vusolo2 wordt het tijd voor een ander merk. Ik weet niet of het beter is, maar slechte producten belonen door steeds nieuwe te kopen is ook geen goed idee. Ik heb een mut@nt hd51aangeschaft. Nu maar eens kijken of die het langer volhoudt. Hij is in ieder geval wel weer snel met het netwerk. Dat bleek dus achteraf ook een probleem buiten de spinners nu en dan, maar je went eraan. Gewoon bijvoorbeeld het laden van de lijst met opnames duurde met de vusolo2 zeker 20 sec. Met de mut@nt staat het er meteen.