MortPlayer für Android

[Spider1996]

Vor allem bräuchte ich erstmal eine weltweit legale Quelle mit brauchbarer Schnittstelle dafür.
Auch wenn die allermeisten hier scheinbar nichts aufs Urheberrecht geben...

Wie wäre es mit last.fm? Die führen doch dort ein Haufen an Liedern und alle auch mit Cover. Wie das da mit der legalität aussieht weiß ich aber nicht. Ich als normaler Mensch kann da eh hin und in meinem Browser das Bild kopieren und so eben runterladen.

Gesendet von meinem SGS3 mit Tapatalk 2

 

[Dadof3]

Ich wäre da auch vorsichtig. Das ganze ist eine rechtliche Grauzone, viele Cover-Angebote im Netz sind illegal, es scheint der Musikbranche nur nicht so wichtig zu sein, um dagegen vorzugehen. Last.fm ist vermutlich sauber, aber ob man die Sachen dort einfach so kopieren und zum Taggen benutzen darf, ist alles andere als klar.

Es gibt genügend gute Software für diesen Zweck. Allerdings nicht für Android, dafür sollte man besser den PC anschmeißen.

 

[mase76]

Woran könnte es dann liegen, dass das Speichern bei manchen Geräten Probleme
macht? Das Initialisieren dauert echt verdammt lange. Und wie gesagt, vom
Widget aus bleibt er oft auf "Initialisiere" stehen. Es passiert dann nichts
mehr. Ich muss dann den Player separat öffnen.

 

[Mort]

Erstmal 'ne Testversion für Zwischendurch. Nix großartig neues, eher kleinere Bugfixes und minimales Tuning.

@peter_jupiter: Seltsam, kann ich bei mir nicht nachvollziehen. Mit "Tags einlesen" (Einstellungen) werden die Tags bei mir immer, ohne nie angezeigt.

@mase76: Tja, wenn ich das mal wüsste... Eigentlich wird da nichts ungewöhnliches benutzt, aber vielleicht gibt's bei manchen Geräten irgendwie Probleme mit dem "Anhängen"-Modus. In der Testversion hab' ich's mal anders probiert, ich hoffe, es hilft.

 

[mase76]

Ja, die Initialisierung ist schon um einiges schneller geworden, dauert aber bei ein
paar tausend Titeln immernoch lange. Kannst du nicht die Option einbauen,
um wirklich manuell die Liste aktualisieren zu können? Dann könnte der
Player wirklich ohne Verzögerung starten. Wenn sich ja wirklich an der
Liste nichts geändert hat, braucht er doch nichts neu einzulesen.
Aber es ist so schon um einiges besser geworden.

 

[Mort]

Tja, eigentlich sollte es beim Aktualisieren=Nie auch so sein. Nur kann der Player die unveränderte Liste nicht laden, wenn sie aus irgendwelchen mysteriösen Gründen nicht gespeichert wurde. Wobei das bei späteren Starts ja jetzt vielleicht doch klappt. Du kannst ja mal nachsehen, ob die Datei Android/data/de.stohelit.folderplayer/folders existiert und nicht nur 0 Bytes groß ist. Außerdem sollte die letzte Zeile "--COMPLETED--" sein (ist 'ne reine Textdatei).
Allerdings braucht auch das Einlesen der gespeicherten Daten etwas Zeit. Ich hatte da offenbar sowohl die Geschwindigkeiten der Speicherkarten bzw. -Leser ("Laufwerke") als auch von Androids Precompiler auf so einigen Geräten überschätzt...

 

[mase76]

Die Datei folders ist korrekt vorhanden. Allerdings nur auf der extSdCard. Aber auf ihr befindet
sich auch die ganze Musik.
Vielleicht wäre eine Datenbank, wie SQLLite schneller.

 

[Mort]

Vielleicht wäre eine Datenbank, wie SQLLite schneller.

Leider auch nicht wirklich, Updates waren da selbst im internen Speicher furchtbar langsam. Außerdem scheint SQLite auf manchen Geräten buggy zu sein - unter Umständen wird da die gesamte Tabelle statt dem Datensatz mit der angegebenen ID aktualisiert, warum habe ich nie ganz herausgefunden.
Vor allem aber ist mir 'ne Datenbank auf externen Medien zu riskant. Da weiß man nie, wie kompatibel die SQLite-Versionen von Custom-ROMs und Updates sind, und was passiert, wenn z.B. mitten im Schreibzugriff der USB-Stick rausgezogen wird.

 

[mase76]

Und dass Android/data/de.stohelit.folderplayer/folders nur auf der externen Karte
existiert, ist korrekt?

 

[Mort]

Und dass Android/data/de.stohelit.folderplayer/folders nur auf der externen Karte
existiert, ist korrekt?

Jepp. Das existiert immer da, wo auch die dazugehörigen Lieder sind. Damit kannst du auch die SD austauschen ohne dass die gespeicherten Daten mit denen einer anderen SD überschrieben werden oder die Lieder der vorherigen SD vergeblich gesucht werden.
Eigentlich sollte dann aber auch diese "folders" eingelesen werden, wenn der Player neu gestartet wird.

 

[mase76]

Dann scheint ja alles korrekt zu sein. Das initialisieren dauert bei mir mit knapp 4000
Titeln fast eine Minute.

 

[Mort]

Dann scheint ja alles korrekt zu sein. Das initialisieren dauert bei mir mit knapp 4000
Titeln fast eine Minute.

Bei "Neu einlesen" oder bei jedem Start? Wieviele Ordner sind das denn ungefähr? Beim Lesen der "alten" Daten wird nämlich eigentlich nur die Ordnerliste und der Ordnerinhalt für die erste und die nächste Datei (also meist derselbe, dann natürlich nur einmal) gelesen, wieviele Dateien das insgesamt sind, ist dann egal.

 

[mase76]

Es dauert bei jedem Start so lange. Es sind etwas über 120 Ordner.

 

[innuendo]

Hallo, Mortplayer stürzt bei mir beim Ordner einlesen gleich zu Beginn ab, allerdings nur, wenn er auf meine 64 GB SDXC-Karte zugreift, entferne ich diese, dann funktioniert es wieder. Habe dieses Problem zwar hier im Forum gefunden, aber leider noch keine Lösung für das Programm. Was kann ich tun, bspw. auch damit er gar nicht erst immer wieder einlesen muss (habe Einstellungen dafür gefunden, aber das ändert nichts an dem fehlerbehafteten Prozesse. Nachstehend mein Logfile


MortPlayer Music crashed

Version: 1.1.15
Build: 200059

--------- Device ---------

Brand: asus
Device: PadFone
Model: PadFone
Id: IMM76I
Product: WW_PadFone
Screen size: xlarge

--------- Firmware ---------

SDK: 15
Release: 4.0.4
Incremental: WW_PadFone-9.20.2.14_WW_9.3.3-0

--------- Stack trace ---------

java.lang.OutOfMemoryError
java.lang.AbstractStringBuilder.enlargeBuffer(AbstractStringBuilder.java:94)
java.lang.AbstractStringBuilder.append0(AbstractStringBuilder.java:145)
java.lang.StringBuilder.append(StringBuilder.java:216)
de.stohelit.folderplayer.playback.FolderManager.readStorageFoldersFromData(FolderManager.java:3821)
de.stohelit.folderplayer.playback.FolderManager.readStorageFolders(FolderManager.java:3658)
de.stohelit.folderplayer.playback.FolderManager.readFolderHierarchy(FolderManager.java:3581)
de.stohelit.folderplayer.playback.PlaybackService$6.readStorageData(PlaybackService.java:3911)
de.stohelit.folderplayer.playback.PlaybackService$9.run(PlaybackService.java:688)


--------- Service ---------

java.lang.OutOfMemoryError
java.lang.AbstractStringBuilder.enlargeBuffer(AbstractStringBuilder.java:94)
java.lang.AbstractStringBuilder.append0(AbstractStringBuilder.java:145)
java.lang.StringBuilder.append(StringBuilder.java:216)
de.stohelit.folderplayer.playback.FolderManager.readStorageFoldersFromData(FolderManager.java:3821)
de.stohelit.folderplayer.playback.FolderManager.readStorageFolders(FolderManager.java:3658)
de.stohelit.folderplayer.playback.FolderManager.readFolderHierarchy(FolderManager.java:3581)
de.stohelit.folderplayer.playback.FolderManager.initFolderInfos(FolderManager.java:204)
de.stohelit.folderplayer.playback.PlaybackService$FolderUpdateThread.run(PlaybackService.java:851)

 

[HerrDesRinges]

Es dauert bei jedem Start so lange. Es sind etwas über 120 Ordner.

ich hatte auch mal das Problem, dass bei mir das Einlesen der Tags unheimlich lange dauerte...

seit ich meinen Tagger "Mp3tag" (Windows) so eingestellt habe, dass er die Tags im "ID3V2.3 ISO-8859-1" Format schreibt und nicht mehr im V2.4-Format, rennt das Einlesen beim MortPlayer quasi nur noch so...

musste bei allen "alten" MP3s auf dem Handy halt nur einmalig die Zeit investieren und die Tags mit Mp3tag neu im 2.3er Format schreiben

vielleicht hilft das ja auch bei Anderen

 

[Mort]

@innuendo:
Technische Erklärung (muss man nicht unbedingt verstehen ;-)): Das liegt an der Speicherverwaltung von Java/Android. Beim Einlesen der Ordnerdaten werden jede Menge eigentlich eher kleiner Speicherabschnitte reserviert, die das System aber dummerweise nicht schnell genug wieder frei gibt, obwohl sie nicht mehr benötigt werden. Außerdem limitiert Android generell den Speicherbedarf jeder App auf 16-48MB (je nach Hardware und Android-Version), egal wieviel frei wäre. Dadurch kommt es zu diesem "Kein Speicher mehr frei"-Absturz.
Und nu? Die Testversionen hier (neue hängt gleich hier dran) verwenden etwas weniger Speicher beim Einlesen, vielleicht hilft's schon. Ansonsten musst du wohl leider warten, bis ich das mit dem geplanten neuen Dateiformaten programmiert habe - da sollen die Daten nicht mehr in Textform gespeichert werden, was dann auch einigen Speicher einspart (statt Zeilen zu lesen, in einzelne Felder zu teilen, und diese in interne Formate umzuwandeln, wird dann direkt der benötigte Wert gelesen. Dafür kann ich dann aber nicht so einfach eingeschickte Dateien auf mögliche Fehler untersuchen...). Oder du löscht/verschiebst ein paar Unterordner und das Zeug in Android/data/de.stohelit.folderplayer, womit die Ordner dann wieder neu eingelesen werden.

@mase76: Bei der angehängten Version hab ich noch ein paar Kleinigkeiten korrigiert, die evtl. zu einem neuen Einlesen trotz "Nie"-Einstellung führen konnten. U.a. hat möglicherweise die "andere Speicherkarte" (/mnt/sdcard) Auswirkungen gehabt, obwohl da eigentlich gar nichts gelesen werden muss. Außerdem hab ich ein paar zusätzliche Log-Ausgaben eingebaut. Wenn's also immer noch so lange dauert, bitte mal ein Log erstellen und schicken/posten (aLogcat o.ä., müsste ein paar Dutzend mal hier im Thread erwähnt sein... ;-)).

Ach ja, vermutlich komme ich erst Sonntag abend oder am Montag wieder an den PC, also keine Panik, wenn erstmal Funkstille herrscht. Übrigens auch der Grund dafür, dass ich die neue Version noch nicht in den Play Store stelle, obwohl sie besser sein dürfte als die dortige Version - wenn doch irgendwas ist, könnte ich's erst ziemlich spät korrigieren.

 

[Mort]

seit ich meinen Tagger "Mp3tag" (Windows) so eingestellt habe, dass er die Tags im "ID3V2.3 ISO-8859-1" Format schreibt und nicht mehr im V2.4-Format, rennt das Einlesen beim MortPlayer quasi nur noch so...

V2.3 und V2.4 sind quasi identisch, bis auf ein paar bei 2.4 eingeführte Tags, die ohnehin vom Player ignoriert werden, und die Möglichkeit, die Tags ans Ende der Datei zu speichern, was aber weder MortPlayer noch die allermeisten Tagger machen (weil's ein unverschämt hoher Aufwand ist, dort den Anfang der Tags zu finden, bzw., ob's überhaupt welche hat).
Vermutlich hast du bei den Einstellungen nebenbei auch das "synchronized"-Format deaktiviert. Dieses Format ist dazu gedacht, dass bei Streams nicht Tag-Daten für Töne gehalten werden, aber derart hirnrissig gemacht, dass es das Parsen extrem verlangsamt. Hat man z.B. beim "normalen" Format drin stehen "hier kommt ein Titel mit 10 Zeichen - '1234567890'" steht beim "sychronized"-Format quasi drin "hier kommt ein Titel mit 10 Zeichen - 'a1ba2b34567890'". Man kann die nicht benötigten Daten also nicht mal problemlos überspringen, weil die Längenangabe nicht stimmt. Wobei "a" und "b" hier nur symbolisch sind. Bestimmte Werte werden durch mehrere andere ersetzt, weil sie sonst eine "hier kommt ein Ton-Abschnitt"-Kennung bilden könnten. Die zu finden und zu überspringen bzw. ersetzen dauert ewig, v.a. wenn Coverbilder und ähnliche größere Datenblöcke enthalten sind...

 

[HerrDesRinges]

V2.3 und V2.4 sind quasi identisch, bis auf ein paar bei 2.4 eingeführte Tags, die ohnehin vom Player ignoriert werden, und die Möglichkeit, die Tags ans Ende der Datei zu speichern, was aber weder MortPlayer noch die allermeisten Tagger machen (weil's ein unverschämt hoher Aufwand ist, dort den Anfang der Tags zu finden, bzw., ob's überhaupt welche hat).
Vermutlich hast du bei den Einstellungen nebenbei auch das "synchronized"-Format deaktiviert. Dieses Format ist dazu gedacht, dass bei Streams nicht Tag-Daten für Töne gehalten werden, aber derart hirnrissig gemacht, dass es das Parsen extrem verlangsamt. Hat man z.B. beim "normalen" Format drin stehen "hier kommt ein Titel mit 10 Zeichen - '1234567890'" steht beim "sychronized"-Format quasi drin "hier kommt ein Titel mit 10 Zeichen - 'a1ba2b34567890'". Man kann die nicht benötigten Daten also nicht mal problemlos überspringen, weil die Längenangabe nicht stimmt. Wobei "a" und "b" hier nur symbolisch sind. Bestimmte Werte werden durch mehrere andere ersetzt, weil sie sonst eine "hier kommt ein Ton-Abschnitt"-Kennung bilden könnten. Die zu finden und zu überspringen bzw. ersetzen dauert ewig, v.a. wenn Coverbilder und ähnliche größere Datenblöcke enthalten sind...

sorry, aber der Mp3tag hat in den Einstellungen wo ich etwas geändert habe keine derartige Option...

ich habe lediglich von ID3V2.4 UTF-8 auf ID3V2.3 ISO-8859-1 umgestellt und die Tags neu geschrieben...

mehr nicht und es hat bei mir "seinerzeit" (= ca einem 1/4 Jahr) eine enorme Temposteigerung gebracht...

kann natürlich sein, dass Mp3tag evtl. bei V2.4 noch irgendetwas "bastelt" was man(n) nicht erwartet... aber evtl. liegt auch genau hier das Problem und es ist bei dem einen oder anderen Tagger -aufgrund von Fehlern des Taggers- dann doch nicht so, dass V2.3 und V2.4 quasi identisch sind

 

[innuendo]

Hallo Mort, danke für die schnelle Antwort - toller Support! Hat leider noch nicht geklappt, nach dem Einlesen weniger Ordner stürzt er wieder ab (Warten bringt da also nichts). Kann auch nicht so viel rüber kopieren, weil da sonst der Speicher voll ist (habe das Prinzip auch nicht ganz verstanden, aber egal). Komischer Weise hatte es am ersten Tag mit der Speicherkarte noch funktioniert... Würde mich freuen, wenn du da bald eine Lösung hättest - habe auch schon gespendet ;-) Beste Grüße Innuendo

 

[peter_jupiter]

Hallo Freunde,
ich möchte versuchen hier nochmals mit Bildern zu zeigen wovon ich spreche mit den Dateinamen. Vielleicht kommt ihr dann besser klar und erkennt was ich für ein Problem habe.
LG
Peterhttps://www.dropbox.com/sh/zj1m6uoftuh74v4/AUMvxv0f7G