Darstellung von Umlauten bei Aufnahme/Wiedergabe
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
Darstellung von Umlauten bei Aufnahme/Wiedergabe
Hi,
ich habe hier nach einigem Suchen viel über die (nicht-)darstellung von Umlauten gelesen, jedoch keine Lösung für mein Problem gefunden. Eventuell weiß jemand Rat.
Ich verwende ein (selbstcompiliertes) Yadi-Image mit CVS-Stand von gestern (aber das problem war schon früher).
Ich habe einen Rechner mit SuSe Linux 9.1 und einer NFS Freigabe auf eine Platte mit vielen Filmen und Audio Tracks. In den Titeln sind auch Umlaute enthalten. Wenn ich mich auf diesem Rechner anmelde, werden diese Umlaute in einem 'ls -l' Befehl normal angezeigt.
Diese NFS Freigabe mounte ich beim Start der DBox.
Problem 1:
Wenn ich mir jetzt mit dem TuxCom, dem Movieplayer oder dem Audioplayer die Dateien aufliste, werden die Umlaute nicht korrekt angezeigt. Es erscheinen nur seltsame Zeichen.
Beispiel: 'ü' = 'ü'
Problem 2:
Wenn ich mit Direct-Recording einen Film aufnehme welcher Umlaute im Titel hat, werden diese Umlaute immer in ein '_' umgewandelt.
Z.b.
PREMIERE6_Die_Pechv_gel.ts (im EPG und in der Infobar steht 'Die Pechvögel').
Kann mir jemand einen Rat geben ??
Gruß,
Joe
ich habe hier nach einigem Suchen viel über die (nicht-)darstellung von Umlauten gelesen, jedoch keine Lösung für mein Problem gefunden. Eventuell weiß jemand Rat.
Ich verwende ein (selbstcompiliertes) Yadi-Image mit CVS-Stand von gestern (aber das problem war schon früher).
Ich habe einen Rechner mit SuSe Linux 9.1 und einer NFS Freigabe auf eine Platte mit vielen Filmen und Audio Tracks. In den Titeln sind auch Umlaute enthalten. Wenn ich mich auf diesem Rechner anmelde, werden diese Umlaute in einem 'ls -l' Befehl normal angezeigt.
Diese NFS Freigabe mounte ich beim Start der DBox.
Problem 1:
Wenn ich mir jetzt mit dem TuxCom, dem Movieplayer oder dem Audioplayer die Dateien aufliste, werden die Umlaute nicht korrekt angezeigt. Es erscheinen nur seltsame Zeichen.
Beispiel: 'ü' = 'ü'
Problem 2:
Wenn ich mit Direct-Recording einen Film aufnehme welcher Umlaute im Titel hat, werden diese Umlaute immer in ein '_' umgewandelt.
Z.b.
PREMIERE6_Die_Pechv_gel.ts (im EPG und in der Infobar steht 'Die Pechvögel').
Kann mir jemand einen Rat geben ??
Gruß,
Joe
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
@ Petgun,
bisher konnte ich damit auch gut leben, aber seitdem ich meine CD und Plattensammlung als MP3 digitalisiert und auf diesem Server abgelegt habe würde ich hier gerne die korrekten Titel sehen.
Du glaubst nicht, wieviele Umlaute plötzlich vorhanden sind, wenn ca. 300 Alben mit durchschnittlich 15 Titeln (~ 4500 Titel) auf einem Server abrufbar sind.
Gruß,
Joe
bisher konnte ich damit auch gut leben, aber seitdem ich meine CD und Plattensammlung als MP3 digitalisiert und auf diesem Server abgelegt habe würde ich hier gerne die korrekten Titel sehen.
Du glaubst nicht, wieviele Umlaute plötzlich vorhanden sind, wenn ca. 300 Alben mit durchschnittlich 15 Titeln (~ 4500 Titel) auf einem Server abrufbar sind.
Gruß,
Joe
-
- Erleuchteter
- Beiträge: 465
- Registriert: Mittwoch 14. August 2002, 20:45
Das Problem ist letztendlich derzeit unloesbar, da es keine Moeglichkeit gibt zu erfahren, in welchem Encoding der Dateiname vorliegt (i.e. in der Regel UTF-8 oder ISO-8859-1 - okay, man kann es schon versuchen zu erraten: utf8 encoding verwenden es sei denn es ist kein gueltiger utf8-string - dies liefert aber nicht immer das erwuenschte resultat).
Imho beruecksichtigt NFS erst ab v4 die entsprechenden mount-optionen (cifs muesste es evtl. koennen - das changelog sagt es zumindest).
Wenn alles in UTF-8 encoded ist, einfach beim compilieren von neutrino dem configure den Parameter "--enable-filesystems-utf8-encoded" zusaetzlich uebergeben.
Auch das http interface des vlc reicht z.B. einfach die Dateinamen unkonvertiert durch - i.e. je nachdem welches encoding der server hat wird der Name falsch oder richtig dargestellt.
Imho beruecksichtigt NFS erst ab v4 die entsprechenden mount-optionen (cifs muesste es evtl. koennen - das changelog sagt es zumindest).
Wenn alles in UTF-8 encoded ist, einfach beim compilieren von neutrino dem configure den Parameter "--enable-filesystems-utf8-encoded" zusaetzlich uebergeben.
Auch das http interface des vlc reicht z.B. einfach die Dateinamen unkonvertiert durch - i.e. je nachdem welches encoding der server hat wird der Name falsch oder richtig dargestellt.
-
- Neugieriger
- Beiträge: 10
- Registriert: Sonntag 25. Juli 2004, 02:25
Hallo,
Theoretisch doch machbar, wenn kleine Prögrammchen, von Titel Umlaut umwandeln kann. Ich kann leider kein Programmierer-Sprache, aber so lange her habe ich von C64er-Basic.
So ungefähr hier:
10 titel$ = EPG
20 umlaut$ = titel$
30 for i = 1 to len(titel$)
40 umlaut$ = left(titel$,i)
50 if umlaut$ = "ü" then print "ue"
60 next i
Hier als Tip geben, damit Ihr vielleicht was einfällt...
Micky.
Theoretisch doch machbar, wenn kleine Prögrammchen, von Titel Umlaut umwandeln kann. Ich kann leider kein Programmierer-Sprache, aber so lange her habe ich von C64er-Basic.
So ungefähr hier:
10 titel$ = EPG
20 umlaut$ = titel$
30 for i = 1 to len(titel$)
40 umlaut$ = left(titel$,i)
50 if umlaut$ = "ü" then print "ue"
60 next i
Hier als Tip geben, damit Ihr vielleicht was einfällt...
Micky.
-
- Erleuchteter
- Beiträge: 465
- Registriert: Mittwoch 14. August 2002, 20:45
@deafmicky: Du hast das Problem nicht verstanden:
Je nach Encoding kann z.B. der Umlaut ä verschiedene Werte besitzen:
0xE4 in ISO8859-1 und Unicode, z.B. 0x84 in CP850.
Doch damit nicht genug: Unicode kann verschieden codiert werden.
Dabei scheint sich UTF8 durchzusetzen:
Ein Zeichen der Nummer 0xE4 wird dabei als 2 Bytes 0xC3, 0xA4 gehandelt.
Wenn nun in einem String die Bytes
0xC3, 0xA4 ist nun nicht klar was es bedeutet, ob ä (utf-8) oder ?ñ (CP850) oder ä (iso-8859-1) oder ?§ (MacRoman) oder etwas anderes (es gibt noch viel mehr encodings, das ist nur ein minimaler ausschnitt) - die ? stehen fuer zeichen die das forum nicht darstellen kann.
Je nach Encoding kann z.B. der Umlaut ä verschiedene Werte besitzen:
0xE4 in ISO8859-1 und Unicode, z.B. 0x84 in CP850.
Doch damit nicht genug: Unicode kann verschieden codiert werden.
Dabei scheint sich UTF8 durchzusetzen:
Ein Zeichen der Nummer 0xE4 wird dabei als 2 Bytes 0xC3, 0xA4 gehandelt.
Wenn nun in einem String die Bytes
0xC3, 0xA4 ist nun nicht klar was es bedeutet, ob ä (utf-8) oder ?ñ (CP850) oder ä (iso-8859-1) oder ?§ (MacRoman) oder etwas anderes (es gibt noch viel mehr encodings, das ist nur ein minimaler ausschnitt) - die ? stehen fuer zeichen die das forum nicht darstellen kann.
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
UTF-8 kommt mir am angenehmsten vom Handling her vor, kein unnötiger Platzverbrauch für die häufigen Zeichen und große Flexibilität bei den Dateinamen.
Ich hatte damit aber auch schon Probleme, Linux war beim letzten Versuch nicht UTF-8-reif und selbst unter Windows wollte der Winamp plötzlich Lieder nicht mehr abspielen weil er die Lieder intern falsch rekodierte und dann auf der Festplatte nicht mehr wiederfand.
Ich glaube, ich hatte dann am Ende das gleiche Problem, unter Samba ging es, unter NFS nicht.
Ich hatte damit aber auch schon Probleme, Linux war beim letzten Versuch nicht UTF-8-reif und selbst unter Windows wollte der Winamp plötzlich Lieder nicht mehr abspielen weil er die Lieder intern falsch rekodierte und dann auf der Festplatte nicht mehr wiederfand.
Ich glaube, ich hatte dann am Ende das gleiche Problem, unter Samba ging es, unter NFS nicht.
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
@ thegoodguy, npq,
ich denke, ich habe das Problem jetzt verstanden. Ich werde heute abend mal einen compile mit der 'enable utf8' Option durchführen und sehen, was dabei herauskommt.
Ich werde den Mount auch mal statt NFS als CIFS (samba sei dank) durchführen.
Mir macht allerdings die Aussage:
Da jetzt die Images gerade im Bereich Streaming und Wiedergabe von Video und Audio immer besser werden, sollte hier auf eine einheitliche Darstellung aller möglichen Zeichen hingearbeitet werden.
Wenn ich die derzeitige Nutzung meiner DBox als MP3- und Video-Server mit Anschluß an die Surroundanlage und an den Beamer sehe und auf 'Knopfdruck' jederzeit Aufnehmen und Wiedergeben kann, kann man doch schon fast von einem fertigen Multimediasystem sprechen.
Ich denke, der Trend wird auch weiter in diese Richtung gehen.
Trotzdem Danke für die hilfreiche 'Aufklärung'.
Gruß,
Joe
ich denke, ich habe das Problem jetzt verstanden. Ich werde heute abend mal einen compile mit der 'enable utf8' Option durchführen und sehen, was dabei herauskommt.
Ich werde den Mount auch mal statt NFS als CIFS (samba sei dank) durchführen.
Mir macht allerdings die Aussage:
ein wenig Sorgen.Linux war beim letzten Versuch nicht UTF-8-reif...
Da jetzt die Images gerade im Bereich Streaming und Wiedergabe von Video und Audio immer besser werden, sollte hier auf eine einheitliche Darstellung aller möglichen Zeichen hingearbeitet werden.
Wenn ich die derzeitige Nutzung meiner DBox als MP3- und Video-Server mit Anschluß an die Surroundanlage und an den Beamer sehe und auf 'Knopfdruck' jederzeit Aufnehmen und Wiedergeben kann, kann man doch schon fast von einem fertigen Multimediasystem sprechen.
Ich denke, der Trend wird auch weiter in diese Richtung gehen.
Trotzdem Danke für die hilfreiche 'Aufklärung'.
Gruß,
Joe
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
Der letzte Versuch ist auch schon etwas her.
Redhat hat schon früh damit begonnen, auf UTF-8 zu setzen, Suse macht es - soweit ich das neulich gesehen habe - wohl auch.
Den aktuellen Stand bei den "üblichen" Programmen und ihrer Eignung für UTF-8 kenne ich nicht, am Anfang hat RedHat wohl viel selber gepatcht.
Redhat hat schon früh damit begonnen, auf UTF-8 zu setzen, Suse macht es - soweit ich das neulich gesehen habe - wohl auch.
Den aktuellen Stand bei den "üblichen" Programmen und ihrer Eignung für UTF-8 kenne ich nicht, am Anfang hat RedHat wohl viel selber gepatcht.
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
Hi,
bevor ich neu compiliere wollte ich mal einen mount mit CIFS testen und siehe da, ich habe ein Problem (Image Yadi vom 12.10.2004, eigenbau):
Im telnet zur DBox:
mount -t cifs //192.168.6.90/shares /mnt/custom -o user=dboxuser,password=dboxpass,unc=//192.168.6.90/shares
Resultat:
mount: Mounting //192.168.6.90/shares on /mnt/filme failed: Invalid argument
dmesg:
CIFS VFS: cifs_mount failed w/return code = -11
Wenn ich den mount allerdings von einem anderen linux (SuSe 9.1) ausführe, habe ich kein problem.
Benutzer und password sind definitv richtig (da es vom anderen linux geht).
Ich kann auf die share auch von jedem Windows PC zugreifen und als laufwerk verbinden.
Was kann das sein ??
Gruß,
Joe
bevor ich neu compiliere wollte ich mal einen mount mit CIFS testen und siehe da, ich habe ein Problem (Image Yadi vom 12.10.2004, eigenbau):
Im telnet zur DBox:
mount -t cifs //192.168.6.90/shares /mnt/custom -o user=dboxuser,password=dboxpass,unc=//192.168.6.90/shares
Resultat:
mount: Mounting //192.168.6.90/shares on /mnt/filme failed: Invalid argument
dmesg:
CIFS VFS: cifs_mount failed w/return code = -11
Wenn ich den mount allerdings von einem anderen linux (SuSe 9.1) ausführe, habe ich kein problem.
Benutzer und password sind definitv richtig (da es vom anderen linux geht).
Ich kann auf die share auch von jedem Windows PC zugreifen und als laufwerk verbinden.
Was kann das sein ??
Gruß,
Joe
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
- Erleuchteter
- Beiträge: 465
- Registriert: Mittwoch 14. August 2002, 20:45
@JoLander: Ich habe deinen ersten Post nochmals gelesen und wollte folgendes nochmals klarstellen:
Wenn dein Server die Dateien bereits UTF-8 encoded vorliegen hat, kannst du auch NFS nehmen, sofern du neutrino mit der option --enable-utf8-encoded baust. Dann sollten alle Zeichen richtig dargestellt werden - ansonsten ist es ein Bug im neutrino code (=> Bug report).
Die Option habe ich vor langer Zeit eingebaut, weil ich selbst alles utf8 encoded habe, alexW damals aber strikt dagegen war dies default zu machen, da windows i.d.R. mit iso-8859-1 daherkommt und nur cifs die option utf8 versteht, nfs v2 und nfs v3 jedoch nicht. Und dann werden nach dem derzeitigen Stand evtl. Strings verkuerzt dargestellt.
Wenn dein Server die Dateien bereits UTF-8 encoded vorliegen hat, kannst du auch NFS nehmen, sofern du neutrino mit der option --enable-utf8-encoded baust. Dann sollten alle Zeichen richtig dargestellt werden - ansonsten ist es ein Bug im neutrino code (=> Bug report).
Die Option habe ich vor langer Zeit eingebaut, weil ich selbst alles utf8 encoded habe, alexW damals aber strikt dagegen war dies default zu machen, da windows i.d.R. mit iso-8859-1 daherkommt und nur cifs die option utf8 versteht, nfs v2 und nfs v3 jedoch nicht. Und dann werden nach dem derzeitigen Stand evtl. Strings verkuerzt dargestellt.
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
@thegoodguy,
der compile läuft gerade. Ich lasse das Yadi-script komplett durchlaufen. Das dauert zwar ca. 3 Stunden aber ich habe dann ein aktuelles System.
Ich bevorzuge NFS, da ich einen Linux Rechner als Server verwende und es da mit NFS überhaupt keine Probleme gibt.
Dem CIFS problem will ich aber trotzdem noch auf den Grund gehen.
Einen Fehler -11 habe ich noch nicht gefunden (selbst bei Google nicht).
Frage: Gebe ich die option --enable-filesystems-utf8-encoded beim ./configure im verzeichnis /cdk an (habe ich jetzt gemacht) oder muß ich das ./configure aus dem /apps/tuxbox/neutrino aufrufen ??
Gruß,
Joe
der compile läuft gerade. Ich lasse das Yadi-script komplett durchlaufen. Das dauert zwar ca. 3 Stunden aber ich habe dann ein aktuelles System.
Ich bevorzuge NFS, da ich einen Linux Rechner als Server verwende und es da mit NFS überhaupt keine Probleme gibt.
Dem CIFS problem will ich aber trotzdem noch auf den Grund gehen.
Einen Fehler -11 habe ich noch nicht gefunden (selbst bei Google nicht).
Frage: Gebe ich die option --enable-filesystems-utf8-encoded beim ./configure im verzeichnis /cdk an (habe ich jetzt gemacht) oder muß ich das ./configure aus dem /apps/tuxbox/neutrino aufrufen ??
Gruß,
Joe
-
- Interessierter
- Beiträge: 49
- Registriert: Sonntag 1. September 2002, 16:40
So,
ich habe jetzt ein neues Image mit der Option '--enable-filesystems-utf8-encoded' erstellt. Leider habe ich bei einem NFS Mount eines exports vom Linux Server keine Änderung festgestellt. Die auf diesem Server abgelegten Dateien mit Umlauten werden auf der DBox immer noch falsch dargestellt.
Allerdings habe ich das Problem mit dem CIFS Mount lösen können.
Wenn ich die Mount-Optionen in Neutrino einstelle, wird immer ein Mountbefehl im format 'mount -t cifs //ip-adresse//freigabe...' erzeugt.
Dieser Befehl erzeugt allerdings einen Kernelfehler den man mit 'dmesg' sehen kann. Danach bringen alle weiteren Versuche nur noch einen Fehler -11 (invalid attribute).
Der Grund liegt beim '//' zwischen id-adresse und der eigentlichen Freigabe. Wenn man den mount Befehl in der Telnetconsole mit einem '/' (//ip-adresse/freigabe) eingibt, klappt es ohne Probleme. Hier ist wohl noch eine Änderung im mount-helper (mount.cifs) notwendig.
Zu den Umlauten ist zu sagen, das sie korrekt dargestellt werden wenn ich den CIFS mount (ohne besondere optionen) verwende. Bei einem NFS mount des selben Verzeichnisses sind die Umlaute durch wirre Zeichen ersetzt (auch bei --enable...utf8...).
Ich habe auch festgestellt, das die Datenübertragung bei einem NFS mount besser ist als bei einem CIFS mount.
Wenn ich Aufnahmen im TS Format wiedergebe, laufen sie bei einem CIFS mount stellenweise mit leichten Aussetzern während es bei einem NFS mount normal durchläuft (jeweils bei Dateien mit höheren Datenraten).
Ich werde jetzt mit den möglichen Optionen der verschiedenen Filesysteme noch ein wenig Testen um eventuell eine bessere Performance bei der Stream-Wiedergabe zu erzielen.
Gruß,
Joe
ich habe jetzt ein neues Image mit der Option '--enable-filesystems-utf8-encoded' erstellt. Leider habe ich bei einem NFS Mount eines exports vom Linux Server keine Änderung festgestellt. Die auf diesem Server abgelegten Dateien mit Umlauten werden auf der DBox immer noch falsch dargestellt.
Allerdings habe ich das Problem mit dem CIFS Mount lösen können.
Wenn ich die Mount-Optionen in Neutrino einstelle, wird immer ein Mountbefehl im format 'mount -t cifs //ip-adresse//freigabe...' erzeugt.
Dieser Befehl erzeugt allerdings einen Kernelfehler den man mit 'dmesg' sehen kann. Danach bringen alle weiteren Versuche nur noch einen Fehler -11 (invalid attribute).
Der Grund liegt beim '//' zwischen id-adresse und der eigentlichen Freigabe. Wenn man den mount Befehl in der Telnetconsole mit einem '/' (//ip-adresse/freigabe) eingibt, klappt es ohne Probleme. Hier ist wohl noch eine Änderung im mount-helper (mount.cifs) notwendig.
Zu den Umlauten ist zu sagen, das sie korrekt dargestellt werden wenn ich den CIFS mount (ohne besondere optionen) verwende. Bei einem NFS mount des selben Verzeichnisses sind die Umlaute durch wirre Zeichen ersetzt (auch bei --enable...utf8...).
Ich habe auch festgestellt, das die Datenübertragung bei einem NFS mount besser ist als bei einem CIFS mount.
Wenn ich Aufnahmen im TS Format wiedergebe, laufen sie bei einem CIFS mount stellenweise mit leichten Aussetzern während es bei einem NFS mount normal durchläuft (jeweils bei Dateien mit höheren Datenraten).
Ich werde jetzt mit den möglichen Optionen der verschiedenen Filesysteme noch ein wenig Testen um eventuell eine bessere Performance bei der Stream-Wiedergabe zu erzielen.
Gruß,
Joe