UnicodeEncodeError auf Linux

  • Zwischenergebnis3: wider Erwarten klappte der Test auch mit einem via smb eingebundenen Music-Verzeichnis auf Windows10 in einer VM. Player + Testscript-Addon liefen wie beim ersten Zwischenergebnis auf OS Linux Leap 15.3, Kodi Matrix 19.4.
    Log-Auszug:

    Ich versuche noch die umgekehrte Fallkonstellation..
    /R

  • Wie schaut dein Script mittlerweile aus?
    Bei mir mit Libreelec 10.0.2 auf dem Rasp3 kommt der fehler. (Pfad der tracks im /storage/music)
    ist doch echt zum verzweifeln...

    edit:
    habe die tracks jetzt mal noch im Pfad /flash abgelegt und auf meinen fritz nas.
    im Pfad flash werden die sonderzeichen nur als Fragezeichen dargestellt.
    im Pfad des NAS wird alles richtig dargestellt.
    in beiden Fällen funktioniert das Speichern und Abspielen.
    Also ein Dateisystemproblem.

  • Wie schaut dein Script mittlerweile aus?

    lediglich diese beiden Stellen sind verändert (Anpassung an die Quelldatei und das encoding in Funktion [definition='1','0']log[/definition] auskommentiert:

    Noch eine interessante Beobachtung: bei einem ersten Test (bevor dein Testaddon eintraf) versuchte ich, in der Funktion PlayAudio meines ARDundZDF-Addon die Umlaute-Datei direkt zu laden. Das schlug fehl - wie im Post 21 mitgeteilt mit "Error surrogates not allowed". Mit zulässigen Dateinamen klappte dein Testscript dann auch in dieser Funktion.
    Sieht so aus, als ob der Player intern die erforderlichen Korrekturen vornimmt. Den C-Code habe ich mir allerdings nicht angesehen - will ich mir auch nicht antun.
    /R

  • hatte die daten bisher mit winscp rüber auf den rasp kopiert.
    jetzt mal in kodi vom NAS auf /storage/music
    dann läuft es auch.

    super - dann wäre auch die Quelle der unverdaulichen Codierung endlich geklärt. Allmächtig scheint dann der Player in Sachen Encodierung nicht zu sein..
    /R

  • nein - im Gegenteil. Ich war selbst überrascht, dass der Player mit den Sonderzeichen im Dateinamen klarkommt. Grundsätzlich haben Sonderzeichen in Dateinamen nichts zu suchen. Erst recht dann nicht, wenn man für verschiedene OS + Dateisysteme programmiert.
    /R

  • na ist doch klar. Auf dem eigenen System funktioniert es ja häufig. Und dein Addon wird ja lokal ebenfalls prima funktionieren (Edit: auch in China). Nur kann man eben nicht erwarten, dass die erzeugten m3u's OS-übergreifend funktionieren. Ich kann mir nicht vorstellen, wie man einen Encoding-Mechanismus integriert, der alle möglichen Codetabellen abdeckt.
    /R

  • Ich kenne die Spielchen auch nur zugut.
    Unter Libre oder Coreelec funktioniert mMn nur ascii Dateinamen zu schreiben / einzulesen, liegt wohl am locale, bzw am verwendetem Charmap ANSI_X3.4-1968.
    Teste das doch mal aus.


    Ich zitier mich mal selbst, sorry dafür das ich selbst nich nicht zum testen kam, macht doch mal ein encode des filenamens auf ascii.

  • hab jetzt mal noch etwas herumgetestet.
    da liegt das problem wohl beim kopieren mit winscp, was die dateinamen fürs zielsystem nicht richtig codiert.

    werde jetzt mal das addon relaible resum entsprechend aufbereiten, testen und auf github bereitstellen.

  • da liegt das problem wohl beim kopieren mit winscp, was die dateinamen fürs zielsystem nicht richtig codiert.

    das ist auch meine Vermutung, nachdem ich diese FAQ-Seite von WinSCP gelesen habe (mit Link auf die WinSCP-Seite UTF-8 Encoding for Filenames). Ansonsten hatte ich ebenfalls eigene leidvolle Erfahrungen mit Encoding bei python. Von daher kann ich deinen Frust nachvollziehen. Allerdings hat die Sprache auch ihre Vorzüge..
    /R

  • Habe das Addon jetzt auf Win10 in Kodi 18, Kodi 19 und Rasp 3 mit Libreelec Kodi 19 getestet. Sollte laufen.

    installiert + ausprobiert - gefällt mir :thumbup:
    /R

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!