Hallo
ich wollt mal fragen, wie groß im Normalfall eine mAirlist.db wird.
ich hab grad eben durch einen Zufall bemerkt, dass ich über eine 1 GB db verfüge, aber eigentlich nicht soviel tracks drin sind.
ich dachte immer db. ist im mb bereich angesiedelt ?
SQLite gibt den durch das Löschen von Datensätzen gewonnenen Speicherplatz nicht immer sofort frei.
In den neuesten Snapshots findest du bei der Konfiguration der DB-Anbindung unter Erweitert einen Button, um die Datenbank zu komprimieren (VACUUM-Befehl).
hm, inzwischen wird das suchen in der db während der sendung ein risikobehaftetes unternehmen,
die eieruhr dreht ewig, die grafik friert ein, musik läuft zwar weiter, aber das kann ja nicht normal sein.
wie kann ich die db optimieren ? (um auszuschliessen, dass es daram liegt)
naja, da sind die cover drin, ja, aber das sind bilder mit 150 x 150 px, also nicht so groß und im ID3Tag enthalten.
und wenn ich die 60 tracks nehme und auf 6 mb komm , find ich das schon ganz schön viel.
ich kann dir aber gerne mal ne test db machen, die 200 tracks entält , so als vergleich.
und dir dann nen link zum download geben, wenn du magst.
Im ID3-Tag oder nicht spielt keine Rolle - mAirList extrahiert die ja und speichert sie in seinem eigenen Format in der Datenbank. Genau wie alle anderen Daten, die aus den ID3-Tags übernommen werden.
Lad mir gerne mal eine Datenbank hoch - ich bin allerdings gerade unterwegs und weiß nicht, wie schnell ich mir das angucken könnte (schlechte Internetverbindung hier).
so, ich hol das nochmal hoch,
das VACUUM hilft zwar etwas, aber inzwischen sind trotzdem probleme mit der performance zu verzeichnen.
die suche eines tracks während der sendung ist fast unmöglich, freeeeeeze.
also beispiel:
sendung beginnt, und ich nutz die suche nach einem track,
beim erstenmal dauert es ewig und freezt sogar (musik läuft weiter)(man muss aber angst haben, dass der laufende track ausreicht von der länge)
sucht man dann direkt nach einem weiterem track, ist das nicht mehr so.
lässt man die suche in ruhe für ca 15 min, beginnt das aufregende suchen von vorn, als wenn die DB schlafen geht.
VACUUM hat bei mir grad 15 min gedauert und mehrmals kam die meldung KEINE RÜCKMELDUNG
Was die DB natürlich mit der Zeit anwachsen lässt sind alte Playlisten, wenn man die nicht regelmäßig löscht. Wie “alt” ist denn deine Datenbank? Ich könnte mal eine Funktion einbauen, mit der sich alle alten Playlisten (älter als x Tage) auf einen Schlag löschen lassen. Bisher geht das nur auf SQL-Ebene.
Ob das die Suche beeinflusst, da bin ich mir gerade nicht sicher.
also wenn du einzelen playlisten meinst mit einzelen tracks, die hab ich fast gar nicht,
da die meisten sendungen über DBplaylistenerstellung gemacht werden.
was sein kann sind sendungen die komplett vorproduziert werden, also die mp3 dann mal eben für eine std. knapp 80 mb gross ist.
aber soviele sind das auch nicht, ca 20.
Ich meine, wie weit die erstellen Playlisten im “Archiv” zurückreichen, also wie viele Wochen/Monate. (Du kannst dich ja in der Wochenübersicht weiter in die Vergangenheit klicken.)