[XMMS] Grote playlist een probleem?

The what goes where now?

Draai XMMS eens vanuit een terminal, misschien dat hij dan wat nuttigs uitspuugt voordat hij crasht...

En anders moet je misschien eens contact opnemen met de author(s)... Het zou wel kunnen dat er gewoon een (ontwerp-) fout in zit waardoor je problemen krijgt bij hele grote playlists, waar ze geen rekening mee hebben gehouden...

zondag 2 juni 2002 18:25

Acties:

odysseus

Debian GNU/Linux Sid

Ehm, wacht. Een playlist van >100GB? Duizend regels in mijn playlist nemen ongeveer 45kB zie ik hier. Dat maakt meer dan twee miljard entries in je playlist om aan die 100GB te komen...ik mag hopen dat ik het verkeerd begrijp, zo veel muziek kun je van je leven niet luisteren

...

Leven is het meervoud van lef | In order to make an apple pie from scratch, you must first create the universe.

zondag 2 juni 2002 18:41

Acties:

The what goes where now?

Op zondag 02 juni 2002 18:25 schreef odysseus het volgende:
Ehm, wacht. Een playlist van >100GB? Duizend regels in mijn playlist nemen ongeveer 45kB zie ik hier. Dat maakt meer dan twee miljard entries in je playlist om aan die 100GB te komen...ik mag hopen dat ik het verkeerd begrijp, zo veel muziek kun je van je leven niet luisteren ... .

Ik neem aan dat hij een paarhonderd gig aan mp3s in zijn playlist bedoelt

Dan is 100 GB mp3s met 5 MB per MP3 => 20.000 MP3s, dat zou nog kunnen (wel veel btw).

zondag 2 juni 2002 19:09

Acties:

mijn mp3 lijst zon 600 stuks gehe niet veel maar genoeg

staan allemaal op een windows share en bij mij crashed Xmms nooit dus dat zou het dnek ik niet wezen ik use dezelfde versie als compukid ik heb alleen Sid ipv woody

zondag 2 juni 2002 19:19

Acties:

sebas

uit puur interesse ... wat doe je met een tig-duizend nummers in je playlist? Of gaat die meer om een theoretisch probleem?

Everyone complains of his memory, no one of his judgement.

zondag 2 juni 2002 20:59

Acties:

Wilke

In het kader van 'ik zet NU een muziekje op en wil de komende 3 maanden m'n computer niet aanraken' ofzo?

Volgens mij overdrijf je het wel een beetje....maar toch is het jammer dat xmms er op crasht. Misschien is het handig toch wat minder extreme playlists samen te stellen, of als dat dan toch moet die opties die je noemt uit te zetten?

Kan me namelijk niet voorstellen dat die info ook maar enigszins interesseert als je toch 20.000+ nummers tegelijk in je playlist hebt staan....

zondag 2 juni 2002 21:21

Acties:

Redlum

Met 60gig aan mp3's heeft die hier geen enkele moeite.
Compile xmms zelf is, dat zal al wel schelen

zondag 2 juni 2002 21:52

Acties:

The what goes where now?

Op zondag 02 juni 2002 21:21 schreef GrimLord het volgende:
Compile xmms zelf is, dat zal al wel schelen

Waarom zou dat al wel schelen?

zondag 2 juni 2002 22:02

Acties:

Tux is lievvv

Op zondag 02 juni 2002 17:50 schreef compukid het volgende:
btw. extreem groot is bij mij een playlist 100 a 200gb of groter.

200 gb aan mp3tjes word rond de 60000 mp3tjes, en dat geloof je zelf ook nog wel? Wie zet er in godsnaam 3 HD's stampvol met MP3'tjes?

Tja

zondag 2 juni 2002 22:25

Acties:

lijkt mij idd ook een beet extreem hoor 100 a 200gb aan mp3 dan weet ik niet hoeveel jij uur achter je pc'tje luisterd maar ik raad je aan te minderen

en ja een entry of 20.000 in je playlist dat ie dan "af en toe" crashed nou vooruit zou ik dan denken hoor, je kan niet alles hebben

zondag 2 juni 2002 22:27

Acties:

Tux is lievvv

Op zondag 02 juni 2002 22:25 schreef The_Dart het volgende:
lijkt mij idd ook een beet extreem hoor 100 a 200gb aan mp3 dan weet ik niet hoeveel jij uur achter je pc'tje luisterd maar ik raad je aan te minderen
en ja een entry of 20.000 in je playlist dat ie dan "af en toe" crashed nou vooruit zou ik dan denken hoor, je kan niet alles hebben

Vinnik ook. Met een playlist van 1000 entries heb je ook genoeg varieteit voor urenlang muziek. Hoef je echt geen 60000 of zelfs maar 10000 voor te hebben.

Tja

zondag 2 juni 2002 22:54

Acties:

The what goes where now?

Op zondag 02 juni 2002 22:27 schreef MadEgg het volgende:
Vinnik ook. Met een playlist van 1000 entries heb je ook genoeg varieteit voor urenlang muziek. Hoef je echt geen 60000 of zelfs maar 10000 voor te hebben.

Dan hoeft XMMS nog niet te crashen.

zondag 2 juni 2002 23:24

Acties:

Tux is lievvv

Op zondag 02 juni 2002 22:54 schreef deadinspace het volgende:

[..]

Dan hoeft XMMS nog niet te crashen.

Probeer een 1000 programma's tegelijk te compileren. Wedden dat ie crashed?

Tja

zondag 2 juni 2002 23:38

Acties:

Redlum

Op zondag 02 juni 2002 21:52 schreef deadinspace het volgende:

[..]

Waarom zou dat al wel schelen?

Omdat xmms blijkbaar moeite heeft met het grote aantal mp3's die hij allemaal moet inladen. Elke vorm van optimalisatie zal hierbij helpen lijkt mij.
Omdat het niet altijd gebeurt lijkt me dit de voornaamste reden.

zondag 2 juni 2002 23:40

Acties:

maandag 3 juni 2002 00:42

de voornaamste optie is gewoon ff rm -rf aan een gig of 50

Acties:

luc

Op zondag 02 juni 2002 17:50 schreef compukid het volgende:
Ik heb meerdere keren gehad dat met extreeem grote playlist xmms wel opstart maar 3 van de 10 keer crasht.
Het lijkt erop dat tijdens 't opzoeken van de tracktijden hij niet gestoord wil worden. Ik heb dan 'read info on load' en 'read info on demand' aan staan.
Het lijkt ook een probleem als de playlist een aantal mp3's bevat die op een windows share staan. Het is meestal xmms 1.2.7 (Debian Woody) die ik gebruik.
Met een kleine playlist (ongeveer 3000 mp3's) gebeurt 't ook heeeel soms...
heeft xmms een logfile?

btw. extreem groot is bij mij een playlist 100 a 200gb of groter.

Ik had 't al bij een kleine 5000 mp3's, zodra je read info on load and demand uitzet is 't over.

maandag 3 juni 2002 02:53

Acties:

maandag 3 juni 2002 03:02

The what goes where now?

Op zondag 02 juni 2002 23:24 schreef MadEgg het volgende:
Probeer een 1000 programma's tegelijk te compileren. Wedden dat ie crashed?

Om te beginnen: Wat is dat voor rare vergelijking? Je compiled geen 1000 programma's tegelijkertijd, omdat dat prima serieel kan (of een paar parallel, voor de efficientie) kan.

20,000+ mp3s in XMMS is iets heel anders.
XMMS moet of zeggen dat hij niet meer MP3s kan laden of gewoon werken. Punt. Een crash is gewoon een bug.

En om je bewering te ontkrachten: ik heb net even geprobeerd 1000 programma's tegelijkertijd te compilen: en er crashte helemaal niks.

Ik heb een programma progje.c gemaakt, en deze gecompiled met de volgende regel:

code:

1	for((i=0;i<1000;i++)); do (sleep 20; gcc -o p_${i} progje.c) & done

Die sleep is om te zorgen dat er eerst wordt geforked voordat het compilen start. Als het compilen eenmaal gestart is, dan zal het forken namelijk langzamer gaan, waardoor niet alle compile-jobs tegelijk plaatsvinden.

Ik heb dit gedaan op een pIII-933, met 512 MB pc133 SDRAM en 1 GB swap.

Het compilen duurde slechts 5 minuten, en de load heeft gepiekt op 967, maar er crashte helemaal niks. Output van uptime, direct na het compilen:

code:

1 2	[marcelm@soyuz fs]$ uptime 02:43:55 up 3 days, 10:53, 3 users, load average: 530.92, 529.29, 273.54

Het aantal files in de directory na het compilen (die ene extra is progje.c):

code:

1 2	[marcelm@soyuz test]$ ls \| wc -l 1001

Op zondag 02 juni 2002 23:38 schreef GrimLord het volgende:
Omdat xmms blijkbaar moeite heeft met het grote aantal mp3's die hij allemaal moet inladen. Elke vorm van optimalisatie zal hierbij helpen lijkt mij.
Omdat het niet altijd gebeurt lijkt me dit de voornaamste reden.

Dat gaat hoogstwaarschijnlijk geen zier helpen, en als het al helpt, dan is het een zeer onbetrouwbare oplossing.
Een crash is een bug, en die moet gewoon gefixt worden. Niet met workarounds als 'zelf compilen', 'load on demand uitzetten' of 'niet zoveel mp3s laden'.

Acties:

Wilke

Op maandag 03 juni 2002 02:53 schreef deadinspace het volgende:

Dat gaat hoogstwaarschijnlijk geen zier helpen, en als het al helpt, dan is het een zeer onbetrouwbare oplossing.
Een crash is een bug, en die moet gewoon gefixt worden. Niet met workarounds als 'zelf compilen', 'load on demand uitzetten' of 'niet zoveel mp3s laden'.

Ben ik het helemaal mee eens, hoewel je nu waarschijnlijk iets doet wat de makers van het product absoluut niet bedoeld hadden, zou het dan een foutmelding moeten geven, crashen is altijd fout. Het is dus een bug...ik weet niet of je op www.xmms.org bugreports kunt submitten (vast wel) en als het kan: doe dat dan!

Verder kunnen wij je hier denk ik niet helpen....

maandag 3 juni 2002 12:25

Acties:

maandag 3 juni 2002 12:55

ik weet alleen nou niet of dit nou echt een bug is dat binnen no-time opgelost moet of zelfs Hoeft worden, ik bedoel hoeveel gekken heb je die nou meer dan 20.000 mp3's hebben beetje vaag hoor.
misschien dat 1 op de miljoen mensen zoveel mp3's hebben en dan nog maar afvragen op welk os/programma ze daarvoor gebruiken.
dit lijkt mij "zoeken" naar een bug in xmms imo

Acties:

maandag 3 juni 2002 15:02

Tux is lievvv

Op maandag 03 juni 2002 12:25 schreef The_Dart het volgende:
dit lijkt mij "zoeken" naar een bug in xmms imo

En patsen natuurlijk

Ff vertellen dat hij 3000 mp3'tjes een KLEINE(!!) playlist vind...

Tja

Acties:

maandag 3 juni 2002 15:41

Tux is lievvv

Op maandag 03 juni 2002 03:02 schreef Wilke het volgende:

[..]

Ben ik het helemaal mee eens, hoewel je nu waarschijnlijk iets doet wat de makers van het product absoluut niet bedoeld hadden, zou het dan een foutmelding moeten geven, crashen is altijd fout. Het is dus een bug...ik weet niet of je op www.xmms.org bugreports kunt submitten (vast wel) en als het kan: doe dat dan!

Verder kunnen wij je hier denk ik niet helpen....

Bugs reporten op:

http://bugs.xmms.org/

Tja

Acties:

maandag 3 juni 2002 23:49

Tux is lievvv

Op maandag 03 juni 2002 02:53 schreef deadinspace het volgende:
[..]
Om te beginnen: Wat is dat voor rare vergelijking? Je compiled geen 1000 programma's tegelijkertijd, omdat dat prima serieel kan (of een paar parallel, voor de efficientie) kan.

Het gaat om de vergelijking tussen twee volstrekt nutteloze dingen.

20,000+ mp3s in XMMS is iets heel anders.
XMMS moet of zeggen dat hij niet meer MP3s kan laden of gewoon werken. Punt. Een crash is gewoon een bug.

Op zich wel, maar evengoed, WAT HEEFT HET VOOR NUT OM 60000 MP3'tjes te laden, om de ID3 tags ook nog on load te laden ook...

En om je bewering te ontkrachten: ik heb net even geprobeerd 1000 programma's tegelijkertijd te compilen: en er crashte helemaal niks.

Ik heb een programma progje.c gemaakt, en deze gecompiled met de volgende regel:
code:
1
for((i=0;i<1000;i++)); do (sleep 20; gcc -o p_${i} progje.c) & done
Die sleep is om te zorgen dat er eerst wordt geforked voordat het compilen start. Als het compilen eenmaal gestart is, dan zal het forken namelijk langzamer gaan, waardoor niet alle compile-jobs tegelijk plaatsvinden.

Ik heb dit gedaan op een pIII-933, met 512 MB pc133 SDRAM en 1 GB swap.

Het compilen duurde slechts 5 minuten, en de load heeft gepiekt op 967, maar er crashte helemaal niks. Output van uptime, direct na het compilen:
code:
1
2
[marcelm@soyuz fs]$ uptime
 02:43:55 up 3 days, 10:53,  3 users,  load average: 530.92, 529.29, 273.54
Het aantal files in de directory na het compilen (die ene extra is progje.c):
code:
1
2
[marcelm@soyuz test]$ ls | wc -l
   1001

Ik heb het dus ff nagedaan, met de file progje.c:

code:

int main(){
 printf("hallo\r\f");
 return 0;
}

Vervolgens jou code om dat 1000 keer te compileren.
Het systeem stond gedurende 15 minuten volledig vast, en na die tijd had ik slechts 259 files, met willekeurige files die ertussen uit miste...
GCC crashte dus wel degelijk.

Dit is geprobeerd op een PIII-450 met 384 MB RAM, 768 MB swap...

Tja

Acties:

Verwijderd

Topicstarter

Op maandag 03 juni 2002 15:41 schreef MadEgg het volgende:

Op zich wel, maar evengoed, WAT HEEFT HET VOOR NUT OM 60000 MP3'tjes te laden, om de ID3 tags ook nog on load te laden ook...

Ik zou misschien bij een kleine radiozender 't systeem van win2k omzetten naar Linux. (o.a. vanwege 't lagere aantal virussen)
Het is logisch dat zo'n systeem betrouwbaar moet zijn. Het zou dan dienen als playlist voor de nacht. En dan heb je snel de neiging om de directory /mp3 te laden. Het is makkelijk zoeken als je dan direct al de id3 tags inleest, en het moet n00b proof zijn. (en ja die zetten dat soort opties aan)
Op m'n eigen pc heb ik uiteraard niet zo'n grote playlist, en ook niet zo'n grote verzameling mp3'tjes.

Ik heb het dus ff nagedaan, met de file progje.c:
code:
1
2
3
4
int main(){
 printf("hallo\r\f");
 return 0;
}
Vervolgens jou code om dat 1000 keer te compileren.
Het systeem stond gedurende 15 minuten volledig vast, en na die tijd had ik slechts 259 files, met willekeurige files die ertussen uit miste...
GCC crashte dus wel degelijk.

Dit is geprobeerd op een PIII-450 met 384 MB RAM, 768 MB swap...

en nog een gratis

error gekregen?
en stond er als je dmesg intikt not iets over out of memory ofzo?
misschien heb je anders wel een bug gevonden in gcc.

(maar wie compiled er nou 1000 programma's tegelijk?

)

dinsdag 4 juni 2002 01:51

Acties:

dinsdag 4 juni 2002 08:47

The what goes where now?

Op maandag 03 juni 2002 12:25 schreef The_Dart het volgende:
ik weet alleen nou niet of dit nou echt een bug is dat binnen no-time opgelost moet of zelfs Hoeft worden, ik bedoel hoeveel gekken heb je die nou meer dan 20.000 mp3's hebben beetje vaag hoor.
misschien dat 1 op de miljoen mensen zoveel mp3's hebben en dan nog maar afvragen op welk os/programma ze daarvoor gebruiken.
dit lijkt mij "zoeken" naar een bug in xmms imo

Daar ben ik het niet mee eens.
Ik vind dat software dat gewoon aan moet kunnen. Als iets netjes gemaakt is, dan gaat het goed met 10 MP3s, en ook met 10,000.
Een error geven dat hij er niet meer aankan is tot daar aan toe, maar crashen is gewoon fout.

Op maandag 03 juni 2002 15:41 schreef MadEgg het volgende:
Vervolgens jou code om dat 1000 keer te compileren.
Het systeem stond gedurende 15 minuten volledig vast, en na die tijd had ik slechts 259 files, met willekeurige files die ertussen uit miste...
GCC crashte dus wel degelijk.

Dit is geprobeerd op een PIII-450 met 384 MB RAM, 768 MB swap...

Neuh, gcc crashte niet, maar
1. Er werden instances afgemaaid door de kernel bij gebrek aan ram (OOM situatie)
2. Een hoop gccs konden niet gestart worden vanwege 'fork: Resource temporarily unavailable'.

1 GB ram+swap (ongeveer wat jij hebt) is namelijk een beetje krap aan voor zo'n stunt.

Verder zit er een limiet op het aantal processes dat gestart kan worden. Met 384 MB ram kan één user ongeveer 3000 processes starten. Maar om één progje te compilen heb je 4 of 5 processes nodig (meerdere gccs, een linker, een bash), dus dat past ook niet.

Vergroot je swap eens naar pak-em-beet anderhalve gig (maak even een swapfile aan), en verdubbel het maximum aantal processes (staat in /proc/sys/kernel/max-threads).
Probeer het dan nog eens.

Acties: