lib.pl & cue

[Siim Salonen]

Hello,
on slow filesystems (over network) initial playlist loading takes too much time.
fp = fopen(buf, "r"); in associated_cue() takes avg 0.1sec per
(non-existing) file

loading playlist containing 8541 tracks:
CONFIG_CUE=n: worker job: 3.901637
CONFIG_CUE=y: worker job: 1226.332155 (20min)

Siim

[Gregory Petrosyan]

Post by Siim Salonen
on slow filesystems (over network) initial playlist loading takes too much time.
fp = fopen(buf, "r"); in associated_cue() takes avg 0.1sec per
(non-existing) file
CONFIG_CUE=n: worker job: 3.901637
CONFIG_CUE=y: worker job: 1226.332155 (20min)

Thanks for reporting! Can you think of any sane way of fixing this
behaviour (I can't come up with any)?

Gregory

[Jason Woofenden]

Post by Siim Salonen
Hello,
on slow filesystems (over network) initial playlist loading takes too much time.
fp = fopen(buf, "r"); in associated_cue() takes avg 0.1sec per
(non-existing) file
CONFIG_CUE=n: worker job: 3.901637
CONFIG_CUE=y: worker job: 1226.332155 (20min)

Doesn't cmus open the audio files to get metadata?

I don't understand how checking for a .cue file would take 600
times longer than getting the metadata out of the audio file.

Is this possibly a quirk of sshfs (eg that it doesn't cache the
non-existance of file paths) or an issue with cmus's concurrency?


- Jason

P.S. -o 'kernel_cache' makes a huge difference with sshfs.

[Siim Salonen]

Post by Jason Woofenden
Doesn't cmus open the audio files to get metadata?
I don't understand how checking for a .cue file would take 600
times longer than getting the metadata out of the audio file.
Is this possibly a quirk of sshfs (eg that it doesn't cache the
non-existance of file paths) or an issue with cmus's concurrency?

When cmus starts without cue compiled in, it just loads lib.pl and cache.
Music directory (in my case sshfs filesystem) is untouched.

Perhaps saving .cue info into cache would help. No need to scan for
.cue every time cmus launches.

Siim

[Gregory Petrosyan]

Post by Siim Salonen

Post by Jason Woofenden
Doesn't cmus open the audio files to get metadata?
I don't understand how checking for a .cue file would take 600
times longer than getting the metadata out of the audio file.
Is this possibly a quirk of sshfs (eg that it doesn't cache the
non-existance of file paths) or an issue with cmus's concurrency?

When cmus starts without cue compiled in, it just loads lib.pl and cache.
Music directory (in my case sshfs filesystem) is untouched.
Perhaps saving .cue info into cache would help. No need to scan for
.cue every time cmus launches.

This sounds reasonable — maybe you can write a patch for it (although
CONFIG_CUE does sound like a much simpler option at the moment :-) ?

Gregory

[Siim Salonen]

Post by Siim Salonen
Perhaps saving .cue info into cache would help. No need to scan for
.cue every time cmus launches.

This sounds reasonable — maybe you can write a patch for it (although
CONFIG_CUE does sound like a much simpler option at the moment :-) ?

Patch created.

Could you help me with metadata reloading when file starts playing
(and ti->duration == 0).
I tried to add cmus_update_tis() to cmus_next() etc but i only get
segfaults. Probably missing something simple.

Siim

[Gregory Petrosyan]

Post by Siim Salonen

Post by Gregory Petrosyan

Post by Siim Salonen
Perhaps saving .cue info into cache would help. No need to scan for
.cue every time cmus launches.

This sounds reasonable — maybe you can write a patch for it (although
CONFIG_CUE does sound like a much simpler option at the moment :-) ?

Patch created.

Thanks, applied (merged with your previous one).

Post by Siim Salonen
Could you help me with metadata reloading when file starts playing
(and ti->duration == 0).
I tried to add cmus_update_tis() to cmus_next() etc but i only get
segfaults. Probably missing something simple.

cmus_update_tis() is async (because it uses worker queue) — maybe you
are passing «&info» there, which becomes invalid after cmus_next()
exits?

Gregory

[Jason Woofenden]

Post by Siim Salonen

Post by Jason Woofenden
Doesn't cmus open the audio files to get metadata?
I don't understand how checking for a .cue file would take 600
times longer than getting the metadata out of the audio file.
Is this possibly a quirk of sshfs (eg that it doesn't cache the
non-existance of file paths) or an issue with cmus's concurrency?

When cmus starts without cue compiled in, it just loads lib.pl and cache.
Music directory (in my case sshfs filesystem) is untouched.

Oh dear! cmus should not be looking through your filesystem when
it's loading the library. Only when you add stuff to the library or
ask for it to be refreshed.

I hope this is a relatively easy fix.

- Jason