| | | jupiter | | 4 Beiträge |  |
| | schrieb am 22.12.12 um 20:57 Uhr | | Hallo, zumindest ein Stream (AVRO) generiert regelmäßig (!) Schmutzzeichen für den Dateinamen mit der Folge s.u. Ich habe das Defaultverzeichnis zur Speicherung. Wie wär's mit einer Begrenzung auf max length? Das ist dann einfacher händisch zu bereinigen.
Gruß
Jupiter
–––––––––––––––––––––––––––––––––––––––––––––––
19:30:40 - Fehler beim Speichern von "Arthur Grumiaux, Viool - Herman Krebbers, Viool - Les Solistes Romands Olv. Arpad Gerecz - Bach Concerto In D Minor For 2 Violins, Bwv 1043, double - 1. Vivace - Bac¾í@‹7õÄí@Œ7õÊí@7õÓí@7õÜí@7õâíðŽ7õçí@7õïíðŽ7õ÷í@7õÿí@7õî@7.mp3": Could not save file because it exceeds the maximum path length (259)
|
|
|
|
| | | Kaefer | | 179 Beiträge |  |
| | schrieb am 22.12.12 um 21:45 Uhr | |  Typisch Klassik! Die haben immer so lange Dateinamen …
Wie die Sonderzeichen zustande kommen, weiß ich allerdings auch nicht.
Als 1.-Hilfe-Maßnahme könnte man in den Einstellungen unter "Dateinamen" etwas ändern.
Dort steht normalerweise: %s\%a - %t (Streamname\Artist - Title)
Man könnte das ändern in z.B.: %t (nur Titel)
Und in der Rubrik "streams" (ebenfalls in den Einstellungen) einen möglichst kurzen Pfad fürs Speichern der Titel wählen. (das würde ich zuerst machen)
|
| | | | Viele Grüße,
Käfer |
|
|
| | | alex | | 2538 Beiträge |  |
| | schrieb am 23.12.12 um 01:26 Uhr | | | Mit der nächsten Build sollte der Titelname hinten abgeschnitten werden. |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | jupiter | | 4 Beiträge | |
| | schrieb am 23.12.12 um 13:33 Uhr zuletzt bearbeitet von jupiter am 23.12.12 um 19:46 Uhr | | @Kaefer:
Danke für den Hinweis. Ist aber nicht so gut, weil (wichtige) Info verloren geht. Das Programm selbst ist aber mächtig, weil es ja einen "Schrottzeichenunterdrücker" enthält - hatte ich übersehen: Einstellungen - Dateinamen - Erweitert. Etwas mühsam, funktioniert aber bis jetzt.
Edit 2012.12.23 18:45:
Funktioniert leider nicht immer. Es werden wohl beliebige Codes erzeugt, die man nicht so einfach mit pattern matching eliminieren kann. Absicht? Mein Test mit streamripper unter ubuntu zeigt hier auch irreguläres Verhalten. Die Tags sind ok, nicht aber die Dateinamen! Allerdings wird die Datei gespeichert. Also wie @alex s.u.
@alex:
Ich glaube, auch eine programmseitige Dateilängenbegrenzung wäre tatsächlich nicht schlecht.
Schöne Feiertage
Jupiter |
|
|
|
| | | alex | | 2538 Beiträge | |
| | schrieb am 24.12.12 um 06:53 Uhr zuletzt bearbeitet von alex am 24.12.12 um 06:53 Uhr | | Ich glaube, auch eine programmseitige Dateilängenbegrenzung wäre tatsächlich nicht schlecht.
Macht das wirklich Sinn? Entweder man schneidet dann aus versehen zu viel ab oder Schrott bleibt dennoch am Dateinamen. Oder sehe ich das falsch? Wie ist die Meinung der anderen? |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | Kaefer | | 179 Beiträge | |
| | schrieb am 24.12.12 um 10:37 Uhr zuletzt bearbeitet von Kaefer am 24.12.12 um 12:24 Uhr | | Wie ist die Meinung der anderen?
Meiner Meinung nach sollte man
1. die ganzen Sonderzeichen aus Dateinamen verbannen (das müsste ja irgendwie gehen … ?), das ist ja wirklich nur Datenmüll
2. falls der Pfad inkl. Dateinamen 259 Zeichen überschreitet, den Dateinamen so kürzen, dass er gerade noch rein passt und gleichzeitig für den User eine Meldung ausgeben, dass er einen kürzeren Pfad (z.B. D:\) wählen soll.
Den Dateinamen auf eine statische Länge zu begrenzen finde ich nicht sehr sinnvoll |
| | | | Viele Grüße,
Käfer |
|
|
| | | jupiter | | 4 Beiträge | |
| | schrieb am 25.12.12 um 11:38 Uhr zuletzt bearbeitet von jupiter am 25.12.12 um 11:38 Uhr | | Wie Käfer schon schrieb - es sind zwei Probleme:
1. Die vom Betriebsystem geforderte Begrenzung der Pfadlänge
2. Die Beseitigung der Sonderzeichen
Zu 1.: Hier sollte die Überschreitung nicht zu einem Fehler mit Nichtspeichern führen, sondern zum Speichern unter einem gekürzten Namen, ggfls. mit Warnhinwies im Log. Der Programmieraufwand ist wahrscheinlich nur wenige Zeilen.
Zu 2.: Im Prinzip ist das ja auch schon vorhanden. Man könnte zusätzlich feste Filter nach verwendeter Code-Tabelle einbauen oder sogar einen Editor für reguläre Ausdrücke. Aber: nicht unerhebliche Programmierarbeit.
Fazit: Der Aufwand muss im Rahmen bleiben. So oft kommt das nicht vor und ich meine, das Programm ist schon so sehr gut. Die störenden Sonderzeichen finden sich in der Regel am Ende des Dateinamens. Daher sollte eine Lösung wie zu 1. reichen. Den Rest kann man ja selbst mit rename-Programmen machen.
Jupiter |
|
|
|
| | | alex | | 2538 Beiträge | |
| | schrieb am 27.12.12 um 06:08 Uhr | | Hi!
Punkt 1:
Sollte erledigt sein. Der Dateiname wird abgeschnitten, wenn er zu lang ist und das Abschneiden möglich ist. Wenn der Pfad 250 Zeichen lang ist und der Name der Datei 50, wird der Name der Datei angepasst, anders geht es ja nicht. Ist der Pfad zu lang wird der Fehler weiterhin ausgegeben, da muss der Benutzer dann eingreifen. Das sollte aber eigentlich nicht passieren denke ich.
Punkt 2:
Wie schon gesagt wurde, so ein Filter ist schon da. Wenn noch weitere Zeichen standardmäßig ignoriert werden sollen, schlagt das hier gerne vor. Ich übernehme das dann, wenn es Sinn macht |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | Yo24hua | | 727 Beiträge |  |
| | schrieb am 27.12.12 um 14:15 Uhr zuletzt bearbeitet von Yo24hua am 27.12.12 um 14:24 Uhr | |
Erklärungsversuch zum Problem:
Bei diesen Sonderzeichen am ende des Titeltextes handelt es sich um einen Binären über lauf. Normalerweise ist im Datenstrom vor beginn die Länge des Textes definiert bzw. sollte am ende des Textes eigendlich ein nicht sichtbares NULL-Zeichen sein welches den Text zum restlichen Datenstrom abgrenzt. Da werden also seitens der Streambetreiber bzw. in deren Übertragungssoftware Fehler gemacht.
Ich habe dieses Phänomen schon des öfteren beobachtet und kann daher bestätigen das dies kein spezifischer Fehler in Streamwriter ist. Diese Textüberläufe kann man bei anderen Programmen (VLC etc.) ebenfalls sehen.
Reguläre Ausdrücke (RegEx):
Es gibt in Streamwriter tatsächlich schon einen "RegEx" Editor, der ist wie folgt zu erreichen:
Senderstream im linken Fensterteil (Kategorien/Favoriten) mit Rechts-Klick die Stream spezifischen Einstellungen auswählen -> In dem Einstellungsdialog die Kategorie Stream -> Erweitert auswählen.
Ich kenne mich mittlerweile schon recht gut mit den "Regulären Ausdrücken" aus und habe schon öfters versucht solche Textüberläufe auf diesem weg zu lösen, das scheitert allerdings wegen der vielen verschiedenen Formate (die Anzahl der Bindestriche bzw. Leerzeichen vor & nach binde strichen schwanken von Titel zu Titel) bei der AVRO-Sendergruppe und anderen ähnlichen Sendern.
Und irgendwie hab ich so manches mal den Eindruck das dieses Perl-RegEx den Textstring "rückwärts" Parsen tut, das macht die Sache noch schwieriger.
Abschluss:
Tja, sieht so aus als ob man das mit den "Schrottzeichen" wohl so hinnehmen und diese manuell entfernen muss. Es sei dem Alex baut irgendwann (das hat meiner Meinung nach absolut keine Priorität) intern einen filter dafür ein.
LG
Yo24hua
|
| | | | Legalität, Radio Verzeichnisse, Diskographie Verzeichnisse, Reguläre Ausdrücke, Videos...:
Yo24hua's streamWriter Special: > > > https://sites.google.com/site/yo24hua < < <
Alles mit Ruhe & Muse, denn Unmöglich sind nur die Dinge, die man nicht tut!
Befreie dich, Befreie dich, Befreie dich und du wirst deinen Weg finden!
··· ¥oæhua ··· |
|
|
| | | alex | | 2538 Beiträge | |
| | schrieb am 29.12.12 um 03:08 Uhr | | | Das ist mal notiert. Natürlich könnte ich von der rechten Seite des Dateinamens nach vorne iterieren und alles, was keine Zahl/Buchstabe ist, bevor die erste Zahl/Buchstabe gefunden wurde, abschneiden. Schauen wir mal! |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | jupiter | | 4 Beiträge | |
| | schrieb am 30.12.12 um 20:04 Uhr | | Hi zusammen,
da ich das Ganze losgetreten hatte, melde ich mich nochmal, obwohl ja alles Notwendige gesagt wurde. Danke für die prompte Reaktion - besonders @alex und einschließlich der Erklärung von Yo24hua. Ich sehe das mit den RegEx mittlerweile auch so. Das ist mehr bei systematischen Trennzeichen angebracht, die bei div. BS das Speichern unmöglich machen. Ich habe schon kommerzielle Progs gehabt, die vor solchen Streams kapitulierten (z.B. ein simples "|"). Da lobe ich mir doch den Streamwriter…
Guten Rutsch
Jupiter
|
|
|
