130 replies to this topic

[littlesat]

BIj deze de lijst van alle UTF-8 issues die ik kan vinden in de Handsat Settings (misschien kan een moderator ook dit topic splitten)

 

Regelmatig de string '\xe2\x97\x8f\xe2\x97\x8f\xe2\x97\x8f\xe2\x97\x8f' (it is makkelijk met een script of zo op te lossen)

maar ook iets als

 

tvplus&deviceMake=samsung&deviceModel=samsung&deviceVersion=unknown&appVersion=unknown&deviceLat=0&deviceLon=0&deviceDNT=%257BTARGETOPT%257D&deviceId=%257BPSID%257D&advertisingId=%257BPSID%257D&us_privacy=1YNY&samsung_app_domain=%257BAPP_DOMAIN%257D&samsung_app_name=%257BAPP_NAME%257D&profileLimit=&profileFloor=&embedPartner=samsung-tvplus:MTV Jovens e M\xe3es'

 

Er zit in ieder geval wel een \x.... in....

 

Verklaart meteen waarom je soms bij zappen in sommige bouquetten een GSOD krijgt....

 

Ik kan er wel een script voor maken die je na DreamSet 'even' everheen moet doen... maar ik moet wel nog even weten/uitzoeken wat ik o.a. met 'M\xe3es' moet doen (wat daar eigenlijk hoort te staan) en andere dingen en hoe je de markers want daar zitten de meeste foutjes in wilt laten zien...

 

 

 hanssat_utf_8_issues.txt   220.22KB   10 downloads

Edited by littlesat, 28 July 2024 - 10:52.

[hro]

Dank. Ondertussen een superdeskundige ict'er gevraagd te kijken naar het probleem, beter: naar een maandelijks eenvoudig toe te passen oplossing (= na downloaden internet settings KOS).

 

Heeft iemand contact met KOS? Dan svp melden. Zelf al gedaan maar nog geen reactie.

[WanWizard]

Het probleem is dreamset zelf.

 

Ik heb net maar even een Windows VM gestart, de laatste versie geinstalleerd, en een sat geimporteerd.  Resultaat: rotzooi.

 Screenshot from 2024-07-28 11-28-17.png   157.14KB   2 downloads

 

Ik heb even in de xml gekeken die Dreamset gebruikt:

<sat name="Eurobird 1 / Astra 1N / Astra 2A / Astra 2B / Astra 2D (28.2°E)" flags="1" position="282" url="http://en.kingofsat.net/freqs.php?&pos=28.2E&standard=Digital&ordre=freq&filtre=no&aff=list"></sat>

Hier staat probleem 1 al in, het teken tussen "(28.2" en "E)", dat rondje, is niet in UTF-8. Op zich logisch, het is een windows bestand, maar Dreamset doet geen conversie, maar stopt het blind in de marker.

 

Dit kan dus worden opgelost door de KingOfSat import XML te korrigeren. De versie van Alex (Lexzie) is wel ok zo te zien.

 

[WanWizard]

Ok, probleem gevonden, en een correctie op bovenstaande:

 

Dreamset is een Windows programma, en gebruikt (logischerwijs) een Windows encoding voor zijn bestanden.

 

Dit impliceert dat je deze bestanden NOOIT rechtstreeks en zonder encoding conversie op een box moet gebruiken, want die wil UTF-8 zien.

 

Nu, als je in Dreamset de lijst naar een box stuurt, dan zorgt FTP voor de conversie, want die weet wat de encoding van bron en doel is. Resultaat is derhalve prima:

 1_0_2_2559_82F_2_11A0000_0_0_0_20240728114844.jpg   131.44KB   2 downloads

 

Ergo, de zips die Hans maakt moet hij niet op zijn PC maken, maar hij moet de lijst naar een box sturen, en DAAR de bestanden zippen.

Edited by WanWizard, 28 July 2024 - 11:52.

[hro]

#69: "Ergo, de zips die Hans maakt moet hij niet op zijn PC maken, maar hij moet de lijst naar een box sturen, en DAAR de bestanden zippen."

 

Ik moet de lijst eerst op de pc maken (mix KOS met eigen lijst). Daarna stuur ik deze naar de receiver. Dan pas ik nog e.e.a. aan zoals het scannen van transponders met T2 MI of multistream (vooral Eutelsat 5 West).

 

Deze aangepaste setting download ik weer naar de pc om het alvorens gezipt op het forum te zetten.

 

Ergo: de rotatingsetting komt niet direct van mijn pc, is eerst in de receiver geweest.

Edited by hro, 28 July 2024 - 11:58.

[WanWizard]

Deze aangepaste setting download ik weer naar de pc om het alvorens gezipt op het forum te zetten.

 

En hier ga je de mist in.

 

Want het ophalen converteert de UTF-8 op de box weer terug naar Windows. Of je dat nu via FTP of via CIFS doen, beide zijn slim genoeg om te detecteren dat de andere kant Windows is...

 

Je moet dus NIET op je PC zippen, maar op de box, de bestanden die in UTF-8 gecodeerd zijn !

 

Daar kunnen we best wel een scriptje voor maken, als je dat lastig vind, maar dat moet wel op de commandline gebeuren.

 

Wat je eventueel ook kunt doen is gewoon heel /etc/enigma2 zippen, die zip overhalen naar je PC, en daar alles er uit gooien wat er niet in hoort. Zolang je de bouquet bestanden maar niet bewerkt.
 

Edited by WanWizard, 28 July 2024 - 12:09.

[hro]

ik lees het maar vrees dat het boven mijn pet gaat.

 

even dit, even dat...

 

de rotatinglijst wordt al meer dan 15 jaar op deze manier gemaakt en nooit een opmerking over een UTF-8 probleem... en plots moet alles anders.

 

uiteraard bereid mee te werken maar "daar alles er uit gooien wat er niet in hoort" is in theorie leuk maar in de praktijk ondoenlijk.

 

En daarbij... als het in de tekst van de vreemde markers zit, daar ga je toch niet op staan?

 

Stream-boeketten zijn 'in eigen beheer' en kunnen handmatig aangepast worden. Het probleem zit meer in de satellietboeketten van KOS. Kan het alternatief Lexzie proberen. Even snel gekeken: ziet er in de markers beter uit. Bolletjes en geen ruitje/? teken...

Edited by hro, 28 July 2024 - 12:17.

[WanWizard]

de rotatinglijst wordt al meer dan 15 jaar op deze manier gemaakt en nooit een opmerking over een UTF-8 probleem... en plots moet alles anders.

 

Ik heb je uitgelegd waarom dit nu een probleem wordt. Python 2 kon er mee leven, Python 3 crasht er op.  En er zijn maar twee mogelijke wegen voorwaarts: of je fixt het probleem, of je stopt er mee.

 

uiteraard bereid mee te werken maar "daar alles er uit gooien wat er niet in hoort" is in theorie leuk maar in de praktijk ondoenlijk.

 

Onzin, dat gaat simpel weg over alle bestanden die niet bouquet.*, *.tv of *.radio heten. Niks moeilijks, maar je moet wel willen.

 

En daarbij... als het in de tekst van de vreemde markers zit, daar ga je toch niet op staan?

 

Stream-boeketten zijn 'in eigen beheer' en kunnen handmatig aangepast worden. Het probleem zit meer in de satellietboeketten van KOS. Kan het alternatief Lexzie proberen. Even snel gekeken: ziet er in de markers beter uit. Bolletjes en geen ruitje/? teken...

 

Je hebt blijkbaar nog steeds niet door wat het probleem is.

 

Het gaat niet alleen om de markers, het gaat om ELK teken dat geen platte ASCII is, alles met accenten, tekens uit oost-europeese tekensets, russische tekens, etc.

 

Het probleem is dat je bestanden in Windows encoding aanlevert voor de ipk's, en daar kan een box NIKS mee.

[littlesat]

Ergo, de zips die Hans maakt moet hij niet op zijn PC maken, maar hij moet de lijst naar een box sturen, en DAAR de bestanden zippen.

Dit is inderdaad het meest eenvoudige... via FTP naar de box zetten en dan weer eventueel met winscp terug zetten en die dan gebruiken...(zippen enz...)

 

Zie mijn overzicht... het zijn vaak inderdaad markers maar het staat ook regelmatig in service namen.... ook ip spul!!!

Edited by littlesat, 28 July 2024 - 12:33.

[littlesat]

de rotatinglijst wordt al meer dan 15 jaar op deze manier gemaakt en nooit een opmerking over een UTF-8 probleem... en plots moet alles anders.

 

Dit is ook pas ECHT een probleem vanaf dat we python 3 images hebben... (vanaf openPLi >= 9.0)... dus vandaar dat we pas de laatste 1-2 jaren ipv 10 er last van hebben. Ik zag oa zefts ergens een u met puntjes erboven dat het mis gaat met een woord Turk....

 

Eigenlijk zijn die settings editors altijd al 'slecht' gemaakt....

Edited by littlesat, 28 July 2024 - 12:35.

[WanWizard]

Eigenlijk zijn die settings editors altijd al 'slecht' gemaakt....

 

Of zich valt dat wel mee, maar ze vertrouwen er op dat de bestanden bij het verzetten naar de box worden omgezet naar UTF-8, voor gebruik,

 

Maar dat is hier niet aan de orde, Hans levert de Windows bestanden aan, niet de bestanden die op de box moeten staan.
 

En het is ook een vervelend dilemma.

 

Als je er van uit gaat dan iedereen die de zip's download, van hier of van andere fora, dat doet om ze zelf in een Windows settings editor in te lezen en dan over te zetten naar de box, dan is het voor die gebruikers geen probleem, sterker nog, die gaan een probleem krijgen als de zips in UTF-8 zijn denk ik.

 

Wellicht is het een optie om vanaf nu gewoon een waarschuwing te plaatsen, op alle plaatsen waar die zips worden geplaatst, dat de bestanden in Windows encoding zijn opgeslagen, en met een settings editor naar de box moeten worden gezet. En niet als zip naar de box, en daar uitpakken bv...

 

Dan zal Tech ze zelf moeten omzetten naar UTF-8, alvorens ze op gitlab worden geupdate, en er ipk's van gemaakt worden. Als hij dat wil, dat is aan hem...

[WanWizard]

Laat maar zitten, dit gaat niet werken.

 

Als ik de zip download, uitpak op linux, en kijk naar bijvoorbeeld  "userbouquet.belgi___vla___wal_.tv", dan staan daar regels in als:

#NAME België (Vla + Wal)
#DESCRIPTION +++TéléSAT Wallonië+++

dat is correct, en blijkbaar wel in UTF-8.

 

Dus het probleem is niet dat de bestanden in Windows encoding zijn, maar dat ze in mixed encoding zijn. Dat gaan we nooit kunnen automatiseren denk ik, hooguit alle zooi er uit strippen.

[WanWizard]

Hans,

 

Kun jij bij gelegenheid een zip maken voor rotating, gebruik makende van Lexzie's XML for de KOS import? Zodat ik kan analyseren waar nog de problemen zitten?

 

Ik denk namelijk dat alle andere zooi in de streams bouqetten zit, veroorzaakt door een foute aanlevering (ooit).

[hro]

Bijlage: rotating-deel van de rotatinglijst, stand vandaag, gemaakt met Lexzie in plaats van zoals normaal KOS.

 

Binnengehaald, opgeslagen met sateditor DreamSet als Enigma 2 ver 4 bestand, ingepakt.

 

Normaal zit er dus mijn eigen hoofdlijst bij maar het probleem zit kennelijk alleen in het rotatingdeel.

 

Hoop dat het helpt want de optie iedere keer alles voor publiceren nalopen zal het niet worden. Dat is ondoenlijk. Hoop dat er begrip voor is.

Dan gebruiken mensen met 9.0 waar Python 3 de basis voor is de rotatinglijst maar niet meer. Want de oorzaak is dus ook in wijziging Python 2 naar 3... niet alleen KOS of DreamSet 'de schuld' geven... ;-) 

 

Bij de stream-boeketten zullen we (ik maar deze niet alleen) goed opletten bij plaatsen. Zelf in de hand. Mogelijk nog fouten in het verleden. Nogmaals: ik heb niets aan regel x of y maar boeket A, zender B. Het blijft opsporen en aanpassen.

Attached Files

•  test Lexzie.zip   492.77KB   5 downloads
•  internet Lexzie .png   8.99KB   2 downloads

Edited by hro, 28 July 2024 - 15:14.

[hro]

Laat maar zitten, dit gaat niet werken.

 

Als ik de zip download, uitpak op linux, en kijk naar bijvoorbeeld  "userbouquet.belgi___vla___wal_.tv", dan staan daar regels in als:

#NAME België (Vla + Wal)
#DESCRIPTION +++TéléSAT Wallonië+++

dat is correct, en blijkbaar wel in UTF-8.

 

Dus het probleem is niet dat de bestanden in Windows encoding zijn, maar dat ze in mixed encoding zijn. Dat gaan we nooit kunnen automatiseren denk ik, hooguit alle zooi er uit strippen.

De marker +++TéléSAT Wallonië+++ heb ik zelf ooit aangemaakt.
Met een accent aigu (é) en umlaut (ë) zou Python 3 geen problemen mee mogen hebben... dat zijn zeer normale leestekens. Net als een cedille (zoals in Curaçao).

 

[WanWizard]

Met een accent aigu (é) en umlaut (ë) zou Python 3 geen problemen mee mogen hebben... dat zijn zeer normale leestekens. Net als een cedille (zoals in Curaçao).

 

Er bestaat niet zoiets ale "normale leestekens" voor een computer. Voor een computer zijn het reeksen van 0 en 1.

 

De representatie daarvan gebeurd door middel van een karakterset, die bepaald welke reeks van 0 en 1 een bepaald teken vormen. De binaire representatie van e-accent-grave in UTF-8 is anders dan in ISO-5589-15, wat Windows gebruikt (in ons deel van de wereld).

 

En dus moet je converteren als je van de een over moet naar de ander, zodat het voor beide leesbaar blijft.

[hro]

Je snapt hoop ik best wel wat ik bedoel met 'normale leestekens'.  De letters en tekens die je maakt op een toetsenbord geschikt voor NL of USA. Geen Chinees of Arabisch... want dat beheers ik niet...

[WanWizard]

Ik weet wat jij bedoeld, maar ik hoop dat jij begrijpt wat ik bedoel.

 

Als jij op je Windows PC een e-accent-aigu in tikt, dan resulteert dan in een andere binaire representatie dan wanneer ik dat doe op mijn Linux laptop. Dus ik kan niet zien wat jij in hebt getikt zonder conversie van de gebruikte encoding.

 

Om het duidelijk te maken, een é in UTF-8 is hexadecimaal C3A9 (2 bytes), in ISO-8859-15 is het hexadecimaal E9 (1 byte). Je moet dus omzetten om het leesbaar te houden.

 

Ik heb nu voorlopig in ons bouwproces een filter opgenomen. Dan is het wellicht niet meer goed leesbaar op de box, maar crasht het in ieder geval niet meer, hangende de oplossing voor dit probleem.

[hro]

Prima.

 

Het zou echter vreemd zijn als een é of ë enzovoort aanleiding voor een crash zou geven. Dan is er toch met Python 3 iets mis...

 

In de voorbeelden ging het om een symbool dat omschreven kan worden als een ruitertje met een vraagteken er in. Dan kan ik me voorstellen dat die python zich verslikt... ;-)

 

In #14 een testbestand gezet conform je verzoek met Lexzie als bron. Als dit werkt is het probleem opgelost voor de satellietboeketten.

De streamboeketten: daar wordt op gelet en handmatig naar piepsysteem aangepast.

Edited by hro, 28 July 2024 - 16:39.

[littlesat]

Python3 is niets mis mee…. Het is er alleen wat strenger mee… dat ruitertje met een vraagteken was eigenlijk een fout teken wat weergegeven werd../ eigenlijk was dit al heel lang fout…. En omdat het mixed is wordt het extra lastig.

Edited by littlesat, 28 July 2024 - 16:52.