Aufnahmen werden im OpenWebif nicht angezeigt

[awz]

Weder noch.
Ich würde mich per FTP (FileZilla) auf die Box verbinden, und mal die Titel der Filme in /media/hdd/movie durchschauen. Da werden sicher nicht allzuviele mit Sonderzeichen im Namen vorkommen.
Oder ein Inhaltsverzeichnis anlegen, und hier anhängen:

Code: Alles auswählen

ls -la /media/hdd/movie > /tmp/Inhalt_movie.txt

Danke für den Tipp. Habe gestern schon über FTP alle Titel mit den Zeichen à drin gelöscht. Das brachte nichts. Wenn ich nun ein Inhaltsverzeichnis anlege, was könnte es mir mehr bringen? Verstehe das mit dem Code und dem "hier anhängen" eh nicht ganz. Wo gebe ich den Code ein (Terminal im open webif) und wo hänge ich das Verzeichnis an? Hier im Thread?

[Papi2000]

Ja, du hast es doch verstanden.

[Mr.Servo]

Wenn ich nach "character '\udcc3' " suche, finde ich einige Python-Issues. Dort steht unter anderem:
'\udcc3\udca0' is supposed to represent the character 'à'. The proper way to write 'à' using Python Unicode escapes is '\u00E0' .

Ja extrem fieses Thema! Es handelt sich dabei um UTF-16 und hierbei wird unterschieden zwischen 16bit (= alles ohne "d") und 32bit (= alles mit "d"):

[table="width: 700", class: grid"]
[tr]
[td]Beispiel[/td]
[td]UTF-16[/td]
[td]Character[/td]
[td]Description[/td]
[/tr]
[tr]
[td]16bit[/td]
[td]"\u0024"[/td]
[td][align=center]$[/align][/td]
[td][/td]
[/tr]
[tr]
[td]32bit[/td]
[td]"\ud83d\ude04"[/td]
[td][align=center]😄[/align][/td]
[td]high_surrogate = "\ud83d" & low_surrogate = "\ude04")[/td]
[/tr]
[/table]

Die Surrogates werden dann zu einer 32bit-Zahl zusammengerechnet. Dabei gibt es noch Unterschiede zwischen der Reihenfolge der Bytes "High/Low" (= UTF-16BE) oder "Low/High" (= UTF-16LE).

Soweit so gut aber trotz dieser klaren Vorgabe halten sich manche Produkte nicht strikt daran (z.B. Windows) und erzeugen UTF-16-Codes mal ohne "high_surrogate" oder mal ohne "low_surrogate". Es liegt nun am Interpreter (hier Python3) ob er den inkorrekten String "frißt" und auch hoffentlich korrekt interpretiert oder korrekterweise eine Fehlermeldung ausspuckt.

Fazit: Also Babylon ist Kinderkrams, hier wurde mal ein richtiger Blumenstrauß an Variationen geschaffen. Toll! Und wer das Auswerten soll, darf raten was er vor sich hat...

Hier kann man sich die Thematik mal reinpfeiffen (viel Spaß): klick hier
Hier kann man mal schön mit rumspielen: klick hier

Hier mal ein Codebeispiel wie das konvertieren klappt ('le' ist Standard in Python3):

Code: Alles auswählen

print("[B]\u0024[/B]".encode('utf-16','surrogatepass').decode('utf-16'))
Ausgabe: '$'

print("[B]\ud83d\ude04[/B]".encode('utf-16','surrogatepass').decode('utf-16'))
Ausgabe: '😄'

Und hier noch "unser" Beispiel:

Code: Alles auswählen

print("[B]\udcc3\udca0[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('iso-8859-1'))
Ausgabe: 'ÜÃÜ'

print("[B]\udcc3\udca0[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('utf-16'))
Ausgabe: '쏜ꃜ'

print("[B]\udcc3[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('iso-8859-1'))
Ausgabe: 'ÜÃ'

print("[B]\udcc3[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('utf-16'))
Ausgabe: '쏜'

Da kann man sich nun die Methode und das Ergebnis selbst aussuchen. Und achja: 'utf-16' (='utf-16le') führt hier übrigens zum ERROR

Das muss irgendwie im WebIF abgefangen werden…

Ja stimmt! Im Zweifel muß der Fehler "einfach" abgefangen werden...

Gruß.....Mr.Servo

[awz]

Ja, du hast es doch verstanden.

leider nicht wirklich: Mit genau deiner Kommandozeile ls -la /media/hdd/movie > /tmp/Inhalt_movie.txt erhalte ich gar nichts

Es gelingt mit zwar mit den Befehl ls / media/hdd/movie eine ellenlange liste abzurufen, die ich hier besser nicht poste. Es sind alle Aufnahme aus diesem Ordner drauf aber damit kann man wohl noch nichts anfangen oder?

Sind vielleicht Anfängerfragen, sorry. Trotzdem Danke für weitere Hilfe. Beste Grüsse Andreas

[awz]

Ja extrem fieses Thema! Es handelt sich dabei um UTF-16 und hierbei wird unterschieden zwischen 16bit (= alles ohne "d") und 32bit (= alles mit "d"):

[table="width: 700", class: grid"]
[tr]
[td]Beispiel[/td]
[td]UTF-16[/td]
[td]Character[/td]
[td]Description[/td]
[/tr]
[tr]
[td]16bit[/td]
[td]"\u0024"[/td]
[td][align=center]$[/align][/td]
[td][/td]
[/tr]
[tr]
[td]32bit[/td]
[td]"\ud83d\ude04"[/td]
[td][align=center]��[/align][/td]
[td]high_surrogate = "\ud83d" & low_surrogate = "\ude04")[/td]
[/tr]
[/table]

Die Surrogates werden dann zu einer 32bit-Zahl zusammengerechnet. Dabei gibt es noch Unterschiede zwischen der Reihenfolge der Bytes "High/Low" (= UTF-16BE) oder "Low/High" (= UTF-16LE).

Soweit so gut aber trotz dieser klaren Vorgabe halten sich manche Produkte nicht strikt daran (z.B. Windows) und erzeugen UTF-16-Codes mal ohne "high_surrogate" oder mal ohne "low_surrogate". Es liegt nun am Interpreter (hier Python3) ob er den inkorrekten String "frißt" und auch hoffentlich korrekt interpretiert oder korrekterweise eine Fehlermeldung ausspuckt.

Fazit: Also Babylon ist Kinderkrams, hier wurde mal ein richtiger Blumenstrauß an Variationen geschaffen. Toll! Und wer das Auswerten soll, darf raten was er vor sich hat...

Hier kann man sich die Thematik mal reinpfeiffen (viel Spaß): klick hier
Hier kann man mal schön mit rumspielen: klick hier

Hier mal ein Codebeispiel wie das konvertieren klappt ('le' ist Standard in Python3):

Code: Alles auswählen

print("[B]\u0024[/B]".encode('utf-16','surrogatepass').decode('utf-16'))
Ausgabe: '$'

print("[B]\ud83d\ude04[/B]".encode('utf-16','surrogatepass').decode('utf-16'))
Ausgabe: '��'

Und hier noch "unser" Beispiel:

Code: Alles auswählen

print("[B]\udcc3\udca0[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('iso-8859-1'))
Ausgabe: 'ÜÃÜ'

print("[B]\udcc3\udca0[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('utf-16'))
Ausgabe: '쏜ꃜ'

print("[B]\udcc3[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('iso-8859-1'))
Ausgabe: 'ÜÃ'

print("[B]\udcc3[/B]".encode('utf-16[B]be[/B]','surrogatepass').decode('utf-16'))
Ausgabe: '쏜'

Da kann man sich nun die Methode und das Ergebnis selbst aussuchen. Und achja: 'utf-16' (='utf-16le') führt hier übrigens zum ERROR


Ja stimmt! Im Zweifel muß der Fehler "einfach" abgefangen werden...

Gruß.....Mr.Servo

Danke für die Erklärungen, verstehe leider fast nur Bahnhof. Frage mal: Habe nur ich auf meiner Box dieses Problem oder ist das bei allen Anwendern des open ATV 7.x images so? im alten Image und unter VTi funktionierte des Auflistung im openwebif nämlich ohne Probleme?

[Papi2000]

Und du bist dir sicher, dass du die Datei mit diesem Sonderzeichen auch schon mit VTi in der Filmliste hattest?
Flash doch zum Spaß deine VTi-Sicherung auf die Box, und schau dir das Ergebnis jetzt aktuell nochmal an.
Dann kannst du immernoch berichten, und deine oATV-Sicherung wieder zurückflashen.
Hier hat das keiner nachvollziehen können. Du bist der einzige, der das klären könnte.

[awz]

habe getan wie geheissen: VTi-Image (15.0.0.) wieder aufgespielt: und die Aufnahmen werden wieder dargestellt!!!

habe dann auch über die Java-Konsole getract. Kommt eine interessante Meldung:

schliesslich wenn man diese "movies 41837" tract kommt man auf folgendes:

ist das nun der Übeltäter? Und wie bekomme ich den weg?

Openwebif unter VTi kann den offenbar handeln. Würde jedoch gerne wieder zum oATV 7.1 wechseln, vor allem weil ich dort die aac-surround-Kanäle in Mehrkanalsound ausspielen kann (geht im Vti leider nicht)

[rdamas]

Nein, das ist nicht der Übeltäter. jQuery wird außerhalb dieser Seite schon geladen.

Der "Übeltäter" ist, dass python3.10 mit dem Unicode nichts anfangen kann. python2.7 so wie es aussieht ist da nicht so pingelig und zeigt irgendwas an.

[awz]

Vielen Dank soweit. Habe jetzt auf 6.4 zurück geflasht. Da lassen sich die Aufnahmen anzeigen. Gibt es Hoffnung, dass Vers 7.x das auch irgendwann kann?

[y456]

Unter OpenATV 7.2 werden die Aufnahmen wieder im Web Interface angezeigt.

Ich glaube unter OpenATV 7.0 und 7.1 hat es unter Firefox nicht funktioniert wegen eines Fehlers in Python.

Wenn man unter OpenATV 7.0 oder 7.1 auf "Aufnahmen" im Webif mit der Maus klickt und dann mit der Maus in das Fenster geht wo die Aufnahmen angezeigt werden sollten kann man Inspect(Q) mit einem rechte-Maus auswählen,
Ein Debug-Fenster geht unten auf. Man klickt auf "Console".
Man sieht
GET http://<ip der box>/ajax/movies ein [HTTP/1.1 500 Internal Server Error 1722ms]
Man klickt links neben der Nachricht unter "Output" um Details zu erhalten.
Unter Response sieht man
web.Server Traceback (most recent call last):
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 158: invalid start byte
/usr/lib/python3.10/site-packages/twisted/web/server.py:227 in process

Sucht man nach "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position " so bekommt man Verweise dass Python daran Schuld wäre.

Mit der heutigen Softwareaktualisierung unter OpenATV 7.1 ist jetzt auch dort der Fehler behoben worden.
Unter OpenATV 7.1 werden jetzt auch dort die Aufnahmen angezeigt.
Unter OpenATV 7.0 bleibt der Fehler.
Unter OpenATV 6.4 werden die Aufnahmen angezeigt

Beim Upgrade auf 7.2 habe ich die Einstellungen gesichtert und dann beim Flashen auf einen Slot der SF8008 die Einstellungen wieder gesichert.
Nach dem Booten habe ich dann die IPK ausgewählt hinter der auch Anwendungen standen.

Um Kodi zum Laufen zu bringen musste ich Kodi entfernen: Blaue-Taste gedrückt; "erweiterungen" auswählen; "Plugins entfernen" auswählen und Kodi deinstallieren.
Ich habe dann unter Windows cmd gestarted und im cmd-Fenster telnet gestartet;
open <ip der Box>
root
<Passwort für root>
opkg update
opkg install kodi-addons-meta enigma2-plugin-extensions-kodi

Gui-Restart
Danach startete Kodi und machte eine Migration der Datenbank der Einstellungen unter Kodi.
Man konnte dann Kodi starten und nichts ging verloren.

OpenATV 7.2 hat die eingelegte Karte sofort nach dem ersten Start von OpenATV 7.2 erkannt, eigene OSCAM Dateien geschrieben und Oscam von OpenATV gestartet.
Man konnte dann das OSCAM WebInterface unter http://<ip der box>:83/ erreichen. Im WebIf auf "Oscam-Webinterface" klicken. (Firefox ... nach Clear Data)
Unter "Files" sieht man:
ConfigDir: /etc/tuxbox/config/oscam-smod/
(Dort steht "smod")

Da ich vorher den OSCAM von Boxpirates benutzte hat mich das erstaunt.
Ich habe dann das mit OpenATV OSCAM getestet.
Blaue-Taste;"Softcam","Softcam-Einrichtung" dort habe ich dann:
Softcam auswählen oscam-smod
Neustart Softcam neu starten
Oscam in Erweiterungen anzeigen Ja

Im BoxPirates Cam-Manager habe ich den Cardserver auf "keine" eingestellt und neu gebootet.
.Die Informationen unter
http://<ip der box>:83/ sind viel detailierter als von BoxPirates.
Man sieht zum Beispiel im Log welche Sender gerade dekodiert werden.

Ich werde mich mehr über das von OpenATV installierte Softcam informieren.

Tolle Leistung. Unter OpenATV 7.2 geht alles was unter OpenATV 7.1 auch ging.

[awz]

Unter OpenATV 7.2 werden die Aufnahmen wieder im Web Interface angezeigt.

Ich glaube unter OpenATV 7.0 und 7.1 hat es unter Firefox nicht funktioniert wegen eines Fehlers in Python.

Wenn man unter OpenATV 7.0 oder 7.1 auf "Aufnahmen" im Webif mit der Maus klickt und dann mit der Maus in das Fenster geht wo die Aufnahmen angezeigt werden sollten kann man Inspect(Q) mit einem rechte-Maus auswählen,
Ein Debug-Fenster geht unten auf. Man klickt auf "Console".
Man sieht
GET http://<ip der box>/ajax/movies ein [HTTP/1.1 500 Internal Server Error 1722ms]
Man klickt links neben der Nachricht unter "Output" um Details zu erhalten.
Unter Response sieht man
web.Server Traceback (most recent call last):
builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position 158: invalid start byte
/usr/lib/python3.10/site-packages/twisted/web/server.py:227 in process

Sucht man nach "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf6 in position " so bekommt man Verweise dass Python daran Schuld wäre.

Mit der heutigen Softwareaktualisierung unter OpenATV 7.1 ist jetzt auch dort der Fehler behoben worden.
Unter OpenATV 7.1 werden jetzt auch dort die Aufnahmen angezeigt.
Unter OpenATV 7.0 bleibt der Fehler.
Unter OpenATV 6.4 werden die Aufnahmen angezeigt.

Also bei mir zeigt es nach wie vor die Aufnahmen im Open Webif nicht an. Habe mittlerweile auch in einer Liste der Aufnahmen nach dem Sonderzeichen à gesucht. Da ist keines mehr drin.
Schade, so ist openATV 7.3.20230722 (2023-07-20) in der neuesten Version für diesen Zweck doch nicht brauchbar.

Aber vielleicht weiss noch jemand Rat?

habe heute 1.8.23 mal wieder auf's VTi-Image gewechselt. Dort lassen sich die Aufnahmen weiterhin problemlos anzeigen. Aber ich hätte gerne openATV, weil die Soundeinstellungen im Radioempfang umfangreicher sind.

[babeser]

Ruf die Seite URL /ajax/movies einmal alleine auf (oder irgendwie aus dem Netzwerk-Tab der Javascript-Konsole mit rechte Maus "Seite in neuem Tab öffnen").

Bei mir gleiches Problem (auch im DreamDroid identisch) - aber der Ajax-Tipp war der Schlüssel zum Erfolg:
In der Konsole-Ansicht (mit F12 aus OpenWebIF, s.o.) hat der Link ("movie") zur Ajax-Seite im neuen Tab geführt, wo dann die Fehlermeldung "File does not exist: /media/hdd/movie/HCmovie" erschien. In /media/hdd/movie stand HCmovie als Link zu /media/autofs/; dort sieht es auch wie ein normales Verzeichnis aus aber beim Versuch dessen Inhalt einzusehen kommt "No such file or directory".
Habe quick-n-dirty den Link in /movie gelöscht und mit einem neuen HCmovie-Link zu /media/hdd/movie ersetzt, et voilà, da ist die Welt in Ordnung!
(Für Vorschläge, wie man's richtig mit autofs löst, bin ich nach wie vor offen!)

Danke rdamas für den Ajax-Tipp!