Our VBA was having trouble with playing. There were gaps of random length in the audio output. The GUI indicated that the library was being rescanned. We had not started the rescan which ran at approximately 05:00. I think the rescan may be causing the gaps. This morning, there was another auto-rescan at about 07:30. I do not recall this happening ever before.
Is rescan now initiated automatically, and if so, how may auto-rescan be disabled?
VortexBox does not have an auto recan feature. It will only recan after a CD has been ripped. Did you install any special plug-ins? Many of these have auto-rescan features.
Andrew said:VortexBox does not have an auto recan feature. It will only recan after a CD has been ripped. Did you install any special plug-ins? Many of these have auto-rescan features.
Andrew, thanks.
I am using MusicIP and SpiceFly SugarCube. Could either of those be causing the rescan?
-mike
Same problem here ; I was just wondering why VBA activity lasts so long, without any play or rip, of course.
Other plugins here :
- Lazy search
- Custom browse
- Custom Scan
- Multi Library
- Wake on LAN (or something like that)
Maybe this will help,
I don't see this problem on my VBA. I have 56 plugins enabled, including MusicIP but not SpiceFly Sugarcube -- perhaps that is the culprit?
Also check to make sure you don't have automatic rescan enabled in SqueezeBox Server:
SBS > Settings > Advanced > Rescan Music Library
The Rescan Timer should be set to "off" if you don't want a daily rescan of your music library.
You should also check the scanner logs in /var/log/squeezeboxserver/scanner.log-... to see exactly when scans were done. Perhaps you can correlate the rescans with activity in the server logs that are also in this directory.
Ron Olsen said:
I don't see this problem on my VBA. I have 56 plugins enabled, including MusicIP but not SpiceFly Sugarcube — perhaps that is the culprit?
Also check to make sure you don't have automatic rescan enabled in SqueezeBox Server:
SBS > Settings > Advanced > Rescan Music Library
The Rescan Timer should be set to "off" if you don't want a daily rescan of your music library.
You should also check the scanner logs in /var/log/squeezeboxserver/scanner.log-… to see exactly when scans were done. Perhaps you can correlate the rescans with activity in the server logs that are also in this directory.
Ron,
Thanks for the detailed troubleshooting suggestions.
. SBS > Settings > Advanced > Rescan Music Library is OFF
(I did not know that option existed)
. I left SBS > Settings > Plugins > Spicefly SugarCube (v2.06) enabled (checked)
. I turned Spicefly SugarCube Status OFF for the SB Duet wireless receiver that
had the interruptions.
. I note that Spicefly SugarCube (SSC) "Comming Up Next" was set ON, and think
that sub-option could be the interruption source. With SSC off, theory is
untested.
. There were no interruptions overnight. (The overnight player repeats a
10-second ambient-noise track to mask external noise.)
. SBS > Music Scan Details shows: Progress information from the previous
scan is not available
I think the lack of information is due the VB GUI upgrade done yesterday.
Updated idea: Maybe the lack of scan information is because SSC, not SBS
initiated the scan.
. Here is the complete scanner log. All times shown are before disabling SSC.
No known actions were taken to initiate the Server scanner actions shown below.
[vortexbox.localdomain ~]# cat /var/log/squeezeboxserver/scanner.log
[10-03-28 19:21:19.6485] main::main (184) Starting Squeezebox Server scanner (v7.4.2, r30227, Thu Feb 25 1 6:02:29 EST 2010) perl 5.010000
[10-03-28 19:21:21.1727] Slim::Music::Import::runImporter (567) Starting Slim::Music::MusicFolderScan scan
[10-03-28 19:24:25.3093] Slim::Music::Import::endImporter (701) Completed Slim::Music::MusicFolderScan Sca n in 184 seconds.
[10-03-28 19:24:25.3125] Slim::Music::Import::runImporter (567) Starting Slim::Music::PlaylistFolderScan s can
[10-03-28 19:24:25.4680] Slim::Utils::Scanner::scanDirectory (320) Found 2 files in /storage/music/playlis t
[10-03-28 19:24:25.4727] Slim::Utils::Scanner::scanDirectory (333) Scanning: /storage/music/playlist/20091 222 – 3 new CDs R&G, Manx, Phelps.m3u
[10-03-28 19:24:26.3438] Slim::Utils::Scanner::scanDirectory (333) Scanning: /storage/music/playlist/Radio Paradise 1-13.m3u
[10-03-28 19:24:26.6753] Slim::Music::Import::runImporter (567) Starting Slim::Plugin::MusicMagic::Importe r scan
[10-03-28 19:24:41.3724] Slim::Music::Import::endImporter (701) Completed Slim::Plugin::MusicMagic::Import er Scan in 14 seconds.
[10-03-28 19:24:41.3769] Slim::Music::Import::runScanPostProcessing (430) Starting merge of various artist s albums
[10-03-28 19:25:27.6361] Slim::Music::Import::endImporter (701) Completed mergeVariousAlbums Scan in 46 se conds.
[10-03-28 19:25:27.6389] Slim::Music::Import::runScanPostProcessing (438) Starting artwork scan
[10-03-28 19:25:27.7218] Slim::Music::Import::endImporter (701) Completed findArtwork Scan in 0 seconds.
[10-03-28 19:25:27.7247] Slim::Music::Import::runScanPostProcessing (462) Starting cleanup of stale track entries
[10-03-28 19:30:54.5201] Slim::Music::Import::endImporter (701) Completed cleanupStaleEntries Scan in 326 seconds.
[10-03-28 19:30:55.3258] Slim::Music::Import::runScanPostProcessing (484) Starting Database optimization.
[10-03-28 19:33:31.8227] Slim::Music::Import::endImporter (701) Completed dbOptimize Scan in 156 seconds.
[vortexbox.localdomain ~]#
I plan to leave the VB configuration unchanged for a couple of days to determine if auto-rescan is suppressed by turning SSC OFF and later re-enable Spicefly SugarCube, with (SSC) "Comming Up Next" set OFF. Then, if there is no auto-rescan or interruption I'll re-enable "Comming Up Next".
Update: I realize that for this test, I will need to disable ALL invocations of Spicefly SugarCube, (SSC is set individually for each player) as any player instance could start the auto-rescan.
Perhaps Sernyl can check some of these items so we will have two sets of data.
-mike
HalfBit said:
[vortexbox.localdomain ~]# cat /var/log/squeezeboxserver/scanner.log
[10-03-28 19:21:19.6485] main::main (184) Starting Squeezebox Server scanner (v7.4.2, r30227, Thu Feb 25 1 6:02:29 EST 2010) perl 5.010000
Check /var/log/squeezeboxserver/server.log -- do you see any activity at that time?
You may also need to check prior server.log files in the /var/log/squeezeboxserver directory if server.log does not cover that time period.
Ron Olsen said:
HalfBit said:
[vortexbox.localdomain ~]# cat /var/log/squeezeboxserver/scanner.log
[10-03-28 19:21:19.6485] main::main (184) Starting Squeezebox Server scanner (v7.4.2, r30227, Thu Feb 25 1 6:02:29 EST 2010) perl 5.010000
Check /var/log/squeezeboxserver/server.log — do you see any activity at that time?
You may also need to check prior server.log files in the /var/log/squeezeboxserver directory if server.log does not cover that time period.
Ron,
Wow! Below spans the time. Looks like SugarCube is IT. Thank you.
[vortexbox.localdomain squeezeboxserver]# cat server.log-20100328 | grep 19:21:
[10-03-24 19:21:16.5106] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:16.5123] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:16.5141] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:16.5168] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:36.5202] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:36.5228] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:36.5253] Plugins::SugarCube::Plugin::wakeUp (879)
[10-03-24 19:21:36.5279] Plugins::SugarCube::Plugin::wakeUp (879)
Even though I have disabled SugarCube on the hardware players, (SqueezeSlave has disapeared – another issue), the wakeUP continues now:
Client;SC Disabled
[10-03-29 09:23:00.6402] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 09:23:20.6424] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 09:23:40.6521] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[vortexbox.localdomain squeezeboxserver]#
I will reboot and see if SugarCube gives up.
Thanks again for the detailed suggestions. You are the man!
-mike
UPdate 20100329 16:42 PDT
With all six hardware players set to disable Spicefly SugarCube, I am seeing:
. . .
[10-03-29 16:35:05.6318] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:05.6348] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:05.6378] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:05.6407] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:05.6424] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:25.6458] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:25.6491] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:25.6521] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:25.6550] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:25.6568] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:45.6605] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:45.6638] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:45.6668] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:45.6698] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[10-03-29 16:35:45.6715] Plugins::SugarCube::Plugin::wakeUp (879)
Client;SC Disabled
[vortexbox.localdomain squeezeboxserver]#
That's an access every 20-seconds or so, to I'm assuming several players. It looks like to stop this Spicefly SugarCube access, the plugin must be removed, not just disabled.
Is anyone else who is using Spicefly SugarCube have any issues like this?
Sernyl said:
Same problem here ; I was just wondering why VBA activity lasts so long, without any play or rip, of course.
Other plugins here :
- Lazy search
- Custom browse
- Custom Scan
- Multi Library
- Wake on LAN (or something like that)
Maybe this will help,
I have them deinstalled, except Lazy search.
It helped a lot.
The mean ripping time is now back to previous values (before plugins installation), i.e. around 15'
But the only ripping task uses 95% of the physical memory : is it normal ?
But the only ripping task uses 95% of the physical memory : is it normal ?
You should not be concerned if the System Status page shows 95% physical memory usage. There really should not be a red line there, since it makes you think something is wrong, when the system is actually behaving as it should.
The important number is kernel + applications, which likely will be below 50%.
All the memory shown as cached is actually available for use if necessary. Linux uses cache to make disk operations more efficient. This memory can be freed if it is needed to run a new process.
...another candidate for Frequently Asked Questions...
Posting Permissions
Reply With Quote
Bookmarks