Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Thomas1970

Pages: [1]
1
Questions / Re: Slow Library scanning
« on: May 26, 2010, 11:52:05 »
And I think you should not try to catch this error with a functionality that consumes a lot of load.
Maybe you could add a "VBR length scan" command to the context menu of files and folders to allow the user to trigger the function?
Also you could trigger the function for each played (and not previously scanned) file?
Yes, I'll add an option to automatically do that scan of not, and maybe do it on the first play.
To start the scan manually, it is already possible in v1.1.x by holding shift when selecting "re-read tags".
Great! I'm waiting for this change to come through via Ubuntu software updates.

2
Questions / Re: Slow Library scanning
« on: May 26, 2010, 11:37:58 »
Does this code change affect only the VBR length scan?
Or does it suppress the folder scan on startup, too?
it only affect the VBR length scan
Cool! I've changed that and now the app works fine! Again: Thanks!
And again: I'm impressed by the performance of the app on my old system!

3
Questions / Re: Slow Library scanning
« on: May 25, 2010, 23:33:21 »
Three questions:
- What's the use of this frame counting check?
It's to determine the real length of some mp3 files, without this the length (and bitrate) is an estimation which is currently only based on the first audio frame if I remember correctly. The estimation should be all right for constant bitrate mp3 files, but without a VBR header, there's no way to tell if the file is constant bitrate or variable bitrate. Other programs might do an estimate on thefirst few frames, but it is sometimes very wrong.

OK, I think I understand.
But my feeling is that a VBR header missing from a VBR file is an error.
And I think you should not try to catch this error with a functionality that consumes a lot of load.
Maybe you could add a "VBR length scan" command to the context menu of files and folders to allow the user to trigger the function?
Also you could trigger the function for each played (and not previously scanned) file?

There is currently no stop button, because it wasn't meant to be stopped, because there was no way to restart it.
If you really want to disable this, you can replace this line in /usr/bin/gmusicbrowser (v1.0.x only) :
Code: [Select]
elsif ($m eq 'l') {push @LengthEstimated,$ID}by this line :
Code: [Select]
elsif ($m eq 'l') { $song[SONG_MISSINGSINCE]=undef } this will clear the list of songs that need a full scan on startup.

I plan to add a way to disable this in v1.1.x

Does this code change affect only the VBR length scan?
Or does it suppress the folder scan on startup, too?

Thanks, Thomas

4
Questions / Re: Slow Library scanning
« on: May 25, 2010, 02:01:25 »
In the log you sent me, the message "No VBR header found, must count all the frames to determine length." shows what is the problem.
mp3 files that do not have a VBR header do not have length information, so unless the file is CBR (constant bit rate), which can't be sure, gmb needs to scan the whole file in order to know the length of the file.
This full scan is slow, I plan to add an option to only do the full scan of the current song, but in the meantime you'll have to wait until it's done, it's only done the first time the song is scanned, so that's not so bad.
I think I have a problem with this schan method.

I'm running GMB on Ubuntu on an old PC with little memory. My library currently contains more than 18000 songs and located on a NAS in my LAN, which is connected via NFS.
GMB really runs smooth in this environment!

This is my problem description:

After each program start, GMB looks for new and changed files. That's good, and the performance is acceptable.
But after the re-scan, the text in the progress window changes to:
"Prüfe Länge/Bitrate von 12767 Dateien ohne VBR-Header...", which means something like:
"Checking length/bitrate of 12767 files without VBR header..."
The progress indicator shows no progress, although on next launch the displayed number is decreased.
There is no "stop" button in this window (there was one during re-scanning).
You can close the window, but the operation seems to continue in background.

This check operation consumes 100% of my CPU, mainly because of iowait.
And because my PC is old, it becomes unusable in this state...

Three questions:
- What's the use of this frame counting check?
- Can you change this operation to not causing cpu iowait?
- Could you please update the window during the check operation such, that the progress indicator really indicates the progress and the number of files to check counts down and maybe add a "stop" button?

Thanks a lot!

Pages: [1]