1. VERY, VERY slow album information retrieving (around 4h for 845 tracks ?!)

2. No possibility to set relaying in "Mount Points" tab in settings

   (In every case it says "Relaying cannot be used on mount points for which the autoDJ is enabled.")

3. There is no album image retreived in 99% of tracks (all tracks have album image embeded, which are shown in any music software)

4. When creating account from template there is no "AutoDJ" tab (in template AutoDJ setting was set as "permitted and enabled")

5. When creating account port setting is ignored (i.e. I'm setting port 8014 and after account is created the port number is like with 'auto' setting, i.e. 8066), updating port number works.

6. There are PHP errors when updating template settings:

Code: [Select]

Warning: Illegal string offset 'account_isreseller' in /usr/local/centovacast/web/class_AccountEditor.php on line 148

Warning: Illegal string offset 'charset_changed' in /usr/local/centovacast/web/class_AccountEditor.php on line 149

Warning: Illegal string offset 'message' in /usr/local/centovacast/web/class_AccountEditor.php on line 150

7. When going into "Files" menu, below error message is shown:

Code: [Select]

populate_readahead_buffer() processing 9 entries from offset 0
{"type":"result","callback":"window.fm.filebrowser.set","data":["\/",

[{"pathname":"\/media","filename":"media","isfolder":true,"details":"","type":"Folder","size":"","time":"Nov 17, 2012

03:40 PM","t":"d","icontype":"dir"},

{"pathname":"\/ondemand","filename":"ondemand","isfolder":true,"details":"","type":"Folder","size":"","time":"Nov 17,

2012 03:27 PM","t":"d","icontype":"dir"},

{"pathname":"\/playlists","filename":"playlists","isfolder":true,"details":"","type":"Folder","size":"","time":"Nov 17,

2012 03:27 PM","t":"d","icontype":"dir"},

{"pathname":"\/sounds","filename":"sounds","isfolder":true,"details":"","type":"Folder","size":"","time":"Nov 17, 2012

03:27 PM","t":"d","icontype":"dir"},

{"pathname":"\/vuimages","filename":"vuimages","isfolder":true,"details":"","type":"Folder","size":"","time":"Nov 17,

2012 03:27 PM","t":"d","icontype":"dir"},

{"pathname":"\/calendar.xml","filename":"calendar.xml","isfolder":false,"details":"","size":65.0,"type":"Unknown\/Binary

File","time":"Nov 22, 2012 08:09 PM","t":"f","icontype":"file"},

{"pathname":"\/playlist.txt","filename":"playlist.txt","isfolder":false,"details":"","size":"85.5KB","type":"Text

File","time":"Nov 22, 2012 08:09 PM","t":"f","icontype":"file"}]]}

8. Tracks web uploading doesn't work (message from google developer tool) :

Code: [Select]

Uncaught TypeError: Cannot read property 'length' of null res.upload.js:28
UploadHandler_multi.extend.onshow res.upload.js:28
Class.extend.show res.upload.js:26
Class.extend.show_upload res.filemanager.js:12
onclick index.php:47

9. Updates are cancelling SSL setting. When SSL is set to ON, after update panel is set to SSL OFF

10. When in SSL mode I'm getting following message in google developer tool:

Code: [Select]

The page at https://domain.com:2199/client/index.php displayed insecure content from

http://domain.com:2197/static/rtpdc/covers/nocover.png.

11. Listeners location map doesn't work in SSL mode (google developer tool):

Code: [Select]

The page at https://domain.com:2199/client/index.php?page=livestats ran insecure content from

http://maps.google.com/maps/api/js?sensor=false.


12. "Tracks" tab in "Report" is showing following message:

Code: [Select]

Invalid response received from server:
populate_readahead_buffer() processing 2 entries from offset 0
{"type":"result","callback":"window.stats.tab_page_objects[4].cb_set_track_reports","data":[[]]}

13. After uploading track and adding it to playlist there is need to restart serwer to apply that track in playlist, any

changes done in playlist settings need serwer restart as well.

14. Playing tracks in order as it is in playlist doesn't work. Tracks are still played differently.

15. "Up" and "Down" buttons in library are not working properly

16. Reindexing tracks by command line is giving me following message:

Code: [Select]

[INF] Updating disk usage...
[INF] Disk usage: 12039
[INF] Indexing files...
[INF] Building file list...
populate_readahead_buffer() processing 6 entries from offset 0
populate_readahead_buffer() processing 18 entries from offset 0
populate_readahead_buffer() processing 3 entries from offset 0
populate_readahead_buffer() processing 35 entries from offset 0
populate_readahead_buffer() processing 512 entries from offset 0
populate_readahead_buffer() processing 335 entries from offset 512
[INF] Progress: 0%;.....

17. Some pages in Source logs are not shown. I.e. I have 3 pages and the second one is blank.

18. When I'm logging in to account with different timezone for a while time displayed is the default server time. After, when "Now is playing" is updated, time is displayed correctly.

This is what I've got now but I will update it if I will find something else.

In few days I will make another list with suggestions

1. VERY, VERY slow album information retrieving (around 4h for 845 tracks ?!)

Honestly I don't see any way this could be a Centova Cast issue.  For each track, Centova Cast has to make an HTTP request over the Internet to the album data service(s) you've configured (Amazon, iTunes, last.fm, etc.)  Once it gets a response, it simply takes the data and saves it... it doesn't do any heavy processing on it.

If it's running slowly, most likely the service you're using happens to be experiencing heavy load at the time and is responding slowly.

2. No possibility to set relaying in "Mount Points" tab in settings
   (In every case it says "Relaying cannot be used on mount points for which the autoDJ is enabled.")

I would have hoped that this would be self-explanatory (both from a common-sense perspective and from reading the error message you quoted above ) but you need to turn off the autoDJ on mount points that you want to use as relays.  eg: Select the mount point, click the "AutoDJ settings" tab, and select "Use autoDJ: No".  Then on the "Relaying" tab, the relaying options will appear.  Obviously you can't have two audio sources for the same mount point, and if the autoDJ is active, it can't also be relaying audio from another stream.

3. There is no album image retreived in 99% of tracks (all tracks have album image embeded, which are shown in any music software)

In your settings, on the "Albums" tab, do you have "Embedded (ID3/metadata)" enabled as an album data source, and configure with an appropriate priority?  If not, any embedded images will be ignored.

If so, try performing a full media library update using:

Code: [Select]

/usr/local/centovacast/sbin/ccmanage reindex USERNAME --updateall

...and see if that pulls in the missing covers.  If not, you can investigate further by running:

Code: [Select]

/usr/local/centovacast/sbin/ccmanage serverdiagnostic USERNAME getalbumdata --nocache --file="filename.mp3" --debug

Replace "filename.mp3" with the filename of one of the MP3s whose cover is not showing up.  The path should be relative to the var/spool/media/ directory for the account... eg: if the file is /usr/local/centovacast/var/vhosts/USERNAME/var/spool/media/foo/bar.mp3 you'd use --file="foo/bar.mp3" (with no leading slash).

That will give you a complete diagnostic report of what Centova Cast is doing when it tries to fetch album covers for your track.  Also, if it's still running slowly, you'll be able to see what step of the process (likely contacting the remote server) is slowing things down.

And finally, if all else fails and if it's always the same set of images that fail to have their covers imported, you can always PM me a link to download one of the affected MP3s and I'll confirm whether it is an actual bug or not.

4. When creating account from template there is no "AutoDJ" tab (in template AutoDJ setting was set as "permitted and enabled")

Thanks for the bug report!  This has been confirmed and will be fixed for the next build.

5. When creating account port setting is ignored (i.e. I'm setting port 8014 and after account is created the port number is like with 'auto' setting, i.e. 8066), updating port number works.

Unable to reproduce this... what server type are you using?  I just created a ShoutCast2 stream with port=8066 and it created on port 8066 as expected.

6. There are PHP errors when updating template settings:
Warning: Illegal string offset 'account_isreseller' in /usr/local/centovacast/web/class_AccountEditor.php on line 148

Again, thank you -- this has been fixed for the next build.

7. When going into "Files" menu, below error message is shown:
populate_readahead_buffer() processing 9 entries from offset 0

This is a known issue which has been reported in at least 2 other threads and was fixed with this morning's build.

8. Tracks web uploading doesn't work (message from google developer tool) :

Should be the result of the issue above which is now fixed.  If it persists, let us know.

9. Updates are cancelling SSL setting. When SSL is set to ON, after update panel is set to SSL OFF

Indeed, we're going to have to set up some kind of include file for custom user settings like this as we do need the ability to update the web interface configuration file from time to time.

10. When in SSL mode I'm getting following message in google developer tool:
...
http://domain.com:2197/static/rtpdc/covers/nocover.png.

Thank you!  Fixed for the next build.

11. Listeners location map doesn't work in SSL mode (google developer tool):

Thanks again!  Fixed for the next build.

12. "Tracks" tab in "Report" is showing following message:
populate_readahead_buffer() processing 2 entries from offset 0

Same issue as no. 7 above.

13. After uploading track and adding it to playlist there is need to restart serwer to apply that track in playlist, any
changes done in playlist settings need serwer restart as well.

That means there is a problem of some sort with your installation and Centova Cast is not able to pull down the next track from the web interface every time the song changes.  When that happens, Centova Cast falls back to a static playlist generated each time the streaming server is started.

Check the "nextsong.log" file in the affected account's log directory to find out what's going on.

14. Playing tracks in order as it is in playlist doesn't work. Tracks are still played differently.

This confirms that you are running from a static playlist as I described in no. 13 above.

15. "Up" and "Down" buttons in library are not working properly

Thanks!  Confirmed and will be fixed for the next build.

16. Reindexing tracks by command line is giving me following message:
populate_readahead_buffer() processing 6 entries from offset 0

Still the same issue as no. 7 and no. 12 above.

17. Some pages in Source logs are not shown. I.e. I have 3 pages and the second one is blank.

Unable to reproduce.  Could you PM me a link to download the affected log file?  Most likely a character encoding issue of some sort that will only manifest with the characters that are in your specific log file.

18. When I'm logging in to account with different timezone for a while time displayed is the default server time. After, when "Now is playing" is updated, time is displayed correctly.

Thanks!  Will be fixed for the next build.

Really appreciate you pointing out all of these issues -- thanks again!

Honestly I don't see any way this could be a Centova Cast issue.  For each track, Centova Cast has to make an HTTP request over the Internet to the album data service(s) you've configured (Amazon, iTunes, last.fm, etc.)  Once it gets a response, it simply takes the data and saves it... it doesn't do any heavy processing on it.

If it's running slowly, most likely the service you're using happens to be experiencing heavy load at the time and is responding slowly.

In your settings, on the "Albums" tab, do you have "Embedded (ID3/metadata)" enabled as an album data source, and configure with an appropriate priority?  If not, any embedded images will be ignored.

If so, try performing a full media library update using:

Code: [Select]

/usr/local/centovacast/sbin/ccmanage reindex USERNAME --updateall

...and see if that pulls in the missing covers.  If not, you can investigate further by running:

Code: [Select]

/usr/local/centovacast/sbin/ccmanage serverdiagnostic USERNAME getalbumdata --nocache --file="filename.mp3" --debug

Replace "filename.mp3" with the filename of one of the MP3s whose cover is not showing up.  The path should be relative to the var/spool/media/ directory for the account... eg: if the file is /usr/local/centovacast/var/vhosts/USERNAME/var/spool/media/foo/bar.mp3 you'd use --file="foo/bar.mp3" (with no leading slash).

That will give you a complete diagnostic report of what Centova Cast is doing when it tries to fetch album covers for your track.  Also, if it's still running slowly, you'll be able to see what step of the process (likely contacting the remote server) is slowing things down.

And finally, if all else fails and if it's always the same set of images that fail to have their covers imported, you can always PM me a link to download one of the affected MP3s and I'll confirm whether it is an actual bug or not.

Well I have allowed just custom and embedded. The rest of sources like iTunes, etc. are disabled from admin area.

Embedded is on the first place.
Executing command "/usr/local/centovacast/bin/ccmanage serverdiagnostic USERNAME getalbumdata --nocache --file="filename.mp3" --debug " is giving following result:

Code: [Select]

[DBG] Performing lookup for artist "Eliminate", title "Body Drop by Stereoliez", album "Dubstep.NET Free Downloads", for ac                   count 15
[DBG]   Not found in cache; dispatching request to driver embedded
[DBG]     Driver returned: image: "tmp:///usr/local/centovacast/var/tmp/cc-app/emb_eliminate_body_drop_by_stereoliez_aad6d8                   45.jpg"
[DBG]       Driver error (embedded): Could not resize cover image file: Non-success response from image daemon
[DBG]   Not found in cache; dispatching request to driver custom
[DBG]     Driver returned:
[DBG] Final result:

0: ""
Result: OK done

I have a lot album covers in tmp:///usr/local/centovacast/var/tmp/cc-app but none of that is used as album cover in CC

Unable to reproduce this... what server type are you using?  I just created a ShoutCast2 stream with port=8066 and it created on port 8066 as expected.

Problem is to be appearing when creating account under reseller account. Under admin area everything is ok.

That means there is a problem of some sort with your installation and Centova Cast is not able to pull down the next track from the web interface every time the song changes.  When that happens, Centova Cast falls back to a static playlist generated each time the streaming server is started.

Check the "nextsong.log" file in the affected account's log directory to find out what's going on.

Now tracks are not indexed automatically.... Could You tell me how to diagnose that issue ?

[DBG]       Driver error (embedded): Could not resize cover image file: Non-success response from image daemon

Excellent, the problem is per above.  The image daemon's logs are in /usr/local/centovacast/var/log/imaged -- please check both error.log and master.log and see if they contain any relevant error messages.

Problem is to be appearing when creating account under reseller account. Under admin area everything is ok.

Ahh, thanks for clarifying.  Resellers aren't allowed to set their own port numbers... most likely that is being enforced when the admin creates an account for a reseller as well.  Added to our issue tracker.

Now tracks are not indexed automatically.... Could You tell me how to diagnose that issue ?

Are you able to import them manually (from the commandline)?  Or does that fail with an error too?

If it fails with an error, what is the error?

If it works then it's a problem of some sort with your cron job -- make sure /etc/cron.d/centovacast contains a line that runs /usr/local/centovacast/bin/mediascan and make sure cron is actually running it.  The mediascan script basically just runs a restricted/automated version of the same "reindex" command you use to import from the commandline.

Excellent, the problem is per above.  The image daemon's logs are in /usr/local/centovacast/var/log/imaged -- please check both error.log and master.log and see if they contain any relevant error messages..

Well error.log with todays date  is empty .
master.log contains a lot lines like this :

Code: [Select]

[26/Nov/2012:19:56:43 +0000]  httpd process 1042 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:19:57:13 +0000]  httpd process 1086 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:19:57:43 +0000]  httpd process 1140 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:19:58:13 +0000]  httpd process 1157 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:19:58:44 +0000]  httpd process 1210 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:19:59:17 +0000]  httpd process 1215 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:20:05:32 +0000]  httpd process 1278 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:20:06:02 +0000]  httpd process 1868 exited due to signal 11 [W=2,H=0]
[26/Nov/2012:20:15:35 +0000]  httpd process 1923 exited due to signal 11 [W=2,H=0]


Are you able to import them manually (from the commandline)?  Or does that fail with an error too?

If it fails with an error, what is the error?

If it works then it's a problem of some sort with your cron job -- make sure /etc/cron.d/centovacast contains a line that runs /usr/local/centovacast/bin/mediascan and make sure cron is actually running it.  The mediascan script basically just runs a restricted/automated version of the same "reindex" command you use to import from the commandline.

After another test i found that tracks are indexed correctly when uplodaed by web uploader.
Tracks uploaded by FTP (as normal user) are not indexed

Well when I'm running reindex command it's importing all tracks.
cron.d/ centovacast contain mediascan line.

Cron logs:

Code: [Select]

Nov 26 20:54:01 XXXXXX CROND[5514]: (ccuser) CMD (/usr/local/centovacast/bin/mediascan >/dev/null)
Nov 26 20:55:01 XXXXXX CROND[5567]: (ccuser) CMD (/usr/local/centovacast/bin/mediascan >/dev/null)
Nov 26 20:55:01 XXXXXX CROND[5568]: (ccuser) CMD (/usr/local/centovacast/bin/mediascan >/dev/null)


FYI, I've followed up with you by responding to your PM.

Hi there.

I have noticed high CPU usage by 2 rpc-control proceses 100% on 3 of 4 CPU cores.
After restarting centova everything is going back to normal but just for a while.

And I have again problem with covers after last update propably:

Code: [Select]

[DBG] Performing lookup for artist "Zero 8", title "Broken Wings", album "80s Pop Goes House 2006 CD2", for account 61
[DBG]   Not found in cache; dispatching request to driver embedded
[DBG]     Driver returned: image: "tmp:///usr/local/centovacast/var/tmp/cc-app/emb_zero_8_broken_wings_c4a1d9a2.jpg"
[DBG]     Resizing image /usr/local/centovacast/var/tmp/cc-app/emb_zero_8_broken_wings_c4a1d9a2.jpg...
[DBG]       Driver error (embedded): Could not resize cover image file: Image daemon request failed: failed to open stream: HTTP request failed!
[DBG]   Not found in cache; dispatching request to driver custom
[DBG]     Driver returned:
[DBG] Final result:

0: ""
Result: OK done


/imaged/master.log

Code: [Select]

[17/Feb/2013:09:50:34 +0000]  worker process 7826 exited with status 0 [W=1,H=0]
[17/Feb/2013:09:50:34 +0000]  httpd startup failed, exiting

In this log file I have around 100 000 lines from tha same date, hour, minut and even SECOND !!!!! something is definetly going wrong
Any ideas ?

After restarting CC panel i have been able reindex track with album cover but still that cover isn't shown in panel and by info widget

Code: [Select]

[DBG] Performing lookup for artist "Zero 8", title "Broken Wings", album "80s Pop Goes House 2006 CD2", for account 61
[DBG]   Not found in cache; dispatching request to driver embedded
[DBG]     Driver returned: image: "tmp:///usr/local/centovacast/var/tmp/cc-app/emb_zero_8_broken_wings_836147d0.jpg"
[DBG]     Resizing image /usr/local/centovacast/var/tmp/cc-app/emb_zero_8_broken_wings_836147d0.jpg...
[DBG]     Image resized
[DBG] Final result:

0:
|  image: "rsz_emb_zero_8_broken_wings_836147d0.jpg"
|  artist: "Zero 8"
|  title: "Broken Wings"
|  album: "80s Pop Goes House 2006 CD2"
|  source: "embedded"
Result: OK done

Another thing would REALLY SUGGEST to change method of detecting album cover and playlist for each track in info widget.
I wrote somehere in forum that tracks which have ") ( [ ]_ '.,';:" chars in tag title, artist or in filename have not detected properly album cover and playlist name this is very often thing that radios are playing tracks in format Artist - title (name of the remix). My radios are most the club music radios with electronic genre tracks where 99,9% have tracks in that format eve if they are oroginal mix they have then artist - title (original mix)

.... 

I have noticed high CPU usage by 2 rpc-control proceses 100% on 3 of 4 CPU cores.
After restarting centova everything is going back to normal but just for a while.

Oddly, I actually just noticed this on one of our staging machines here today as well.  I've pushed a new cc-control build out to the download servers that has debugging enabled -- if this happens again, and you're able to provide me access to a server that it's happening on with the new build installed, that should make tracking it down easy.  (We're of course testing with the debug build here as well to see if we can reproduce it locally.)

In this log file I have around 100 000 lines from tha same date, hour, minut and even SECOND !!!!! something is definetly going wrong

You only quoted 2 lines.   What do the other 100,000 say?  (Just a representative example of a page of entries would be useful.)

After restarting CC panel i have been able reindex track with album cover but still that cover isn't shown in panel and by info widget

Take a look at /usr/local/centovacast/var/vhosts/USERNAME/var/www/covers/rsz_emb_zero_8_broken_wings_836147d0.jpg and see what it contains... is it a valid image?

I wrote somehere in forum that tracks which have ") ( [ ]_ '.,';:" chars in tag title, artist or in filename have not detected properly album cover and playlist name

That absolutely should not be the case, and would represent a bug.  If you can provide an example MP3 that exhibits this problem I'd be happy to investigate.

The only character that should throw off the detection code is the dash (-).  eg: Sometimes people do braindead thinsg like setting the ID3 tags such that the artist name is "Foo" and the track name is "Bar - Baz".  The SHOUTcast/IceCast server doesn't pass back the individual components of the track information, it just presents it as a single string, so it ends up returning "Foo - Bar - Baz".

Centova Cast says "oh! three dashes! that must be artist - album - title" and it parses it as such.  And then it can't find a song named "Baz" (since the song is actually named "Bar - Baz") so the track is not identified correctly.

All other extraneous symbols are stripped by the lookup code, so they should have no effect at all.

this is very often thing that radios are playing tracks in format Artist - title (name of the remix)

We also strip out anything in parentheses at the end of the string (among a variety of other cleanups), so this shouldn't have any impact either.

My radios are most the club music radios with electronic genre tracks where 99,9% have tracks in that format eve if they are oroginal mix they have then artist - title (original mix)

Again, if you have an MP3 whose artist is formatted as "artist name" and its title is formatted as "title (bla bla)", and Centova Cast processes it incorrectly, that's a bug -- just send over the MP3 and I'm happy to investigate.

You only quoted 2 lines.   What do the other 100,000 say?  (Just a representative example of a page of entries would be useful.)

All the 100,000 lines are the same.....

/usr/local/centovacast/var/vhosts/USERNAME/var/www/covers/rsz_emb_zero_8_broken_wings_836147d0.jpg and see what it contains... is it a valid image?

All images in tmp directory are fine and properly generated.

I think i found partial problem with "imaged".
When I'm running command:

Code: [Select]

/usr/local/centovacast/bin/ccmanage serverdiagnostic rmi9 getalbumdata --nocache --file="song.mp3"

The cover image is created as it should be but it's not assigned to track.

Next I'm trying to "Re-index album" option from web-interface and there is something assigned to track but there is no file with this name.
The "Re-index album" option doing something wrong because after running it Centova panel stops working.
I'm getting error about AJAX (AJAX request failed (504).) and then I can't open any page of CC panel.
Restart Centovacast and everything is going back to normal.
(WIERD)

Sometimes when I run:

Code: [Select]

/usr/local/centovacast/bin/ccmanage serverdiagnostic rmi9 getalbumdata --nocache --file="MP3/Adams Project - Shoot Your Shot ( Radio Mix ).mp3"

I'm getting this error:

Code: [Select]

[DBG] Performing lookup for artist "Adams Project", title "Shoot Your Shot", album "Italo Boot Mix (Megamix By Riba And Jmk) 2008 CD2", for account 61
[DBG]   Not found in cache; dispatching request to driver embedded
[DBG]     Driver returned: image: "tmp:///usr/local/centovacast/var/tmp/cc-app/emb_adams_project_shoot_your_shot_4a3bf6db.jpg"
[DBG]     Resizing image /usr/local/centovacast/var/tmp/cc-app/emb_adams_project_shoot_your_shot_4a3bf6db.jpg...
[DBG]       Driver error (embedded): Could not resize cover image file: Image daemon request failed: failed to open stream: HTTP request failed!
[DBG] Final result:

0: ""
Result: OK done


In attachment file with copied output from SSH after running:

Code: [Select]

/usr/local/centovacast/bin/ccmanage reindex rmi9 --updateall --debug

 

I thing that "imged" is getting stuck after few resizings.

I can see that even when restarting centovacast;
Stopping Centova Cast: cc-ftpd cc-web cc-appserver cc-control cc-imaged (now wait few seconds )
And then everything starts.

Another attempts to restart CC stright away are done MUCH qicker.

Anyway "Covers" are really good option which customers like a lot. But for now is to "buggy"

Now I have encouring high load and 100% CPU usegae by Imaged

Hmm, sorry, I responded to this the other day but must have screwed up as I see my reply never ended up being posted.  Sorry about that, I'll summarize what I originally said below.

All the 100,000 lines are the same.....

This shouldn't be possible.  Note that our error messages often vary by only a word or two, but those distinctions can completely change the meaning of the message.  imaged exits almost immediately after logging second line you quoted so there should be no opportunity for it to loop like that.  Are you sure the lines are EXACT repetitions of what you quoted?

I think i found partial problem with "imaged".
When I'm running command:

Code: [Select]

/usr/local/centovacast/bin/ccmanage serverdiagnostic rmi9 getalbumdata --nocache --file="song.mp3"

The cover image is created as it should be but it's not assigned to track.

That's a server diagnostic, it's not supposed to make any changes to the track.  It just displays the result of a track lookup.

The "Re-index album" option doing something wrong because after running it Centova panel stops working.
I'm getting error about AJAX (AJAX request failed (504).) and then I can't open any page of CC panel.
Restart Centovacast and everything is going back to normal.

That means the re-index operation is still running.  When it starts, the albums pane should be greyed out and a "throbber" image should be displayed over top of it.  Are you waiting for the throbber to disappear?  If not, the operation has not yet completed and you will get the exact symptoms you described if you navigate away.  (This is to do with how PHP sessions work.)

Sometimes when I run:
...
I'm getting this error:
...
[DBG]       Driver error (embedded): Could not resize cover image file: Image daemon request failed: failed to open stream: HTTP request failed!

That means imaged isn't working (or isn't running) at the time of the request.  Clearly something is not working right with imaged on your server, it's just a matter of figuring out what.

Now I have encouring high load and 100% CPU usegae by Imaged

The next time it does this, can you run:

Code: [Select]

strace -p <pid>
...where <pid> is the PID of the imaged instance using 100% CPU?  It will probably start dumping loads of data to the console; just hit Ctrl+C after a second or two and then PM me the last few dozen lines.  That should help me to pinpoint what the heck it's doing when it goes crazy like this.

This shouldn't be possible.  Note that our error messages often vary by only a word or two, but those distinctions can completely change the meaning of the message.  imaged exits almost immediately after logging second line you quoted so there should be no opportunity for it to loop like that.  Are you sure the lines are EXACT repetitions of what you quoted?

Lines are NOT exact but have the same meaning, there is just diference with PID number.
I have attached my last master.log anyway.

master.zip

That's a server diagnostic, it's not supposed to make any changes to the track.  It just displays the result of a track lookup.

Ohh.. I understand now.

That means the re-index operation is still running.  When it starts, the albums pane should be greyed out and a "throbber" image should be displayed over top of it.  Are you waiting for the throbber to disappear?  If not, the operation has not yet completed and you will get the exact symptoms you described if you navigate away.  (This is to do with how PHP sessions work.)

After clicking Re-index Album I'm not doing anything else, just waiting...

The next time it does this, can you run:

Code: [Select]

strace -p <pid>
...where <pid> is the PID of the imaged instance using 100% CPU?  It will probably start dumping loads of data to the console; just hit Ctrl+C after a second or two and then PM me the last few dozen lines.  That should help me to pinpoint what the heck it's doing when it goes crazy like this.

This is all strace when I was reindexing tracks :

Code: [Select]

# strace -p 21069
Process 21069 attached - interrupt to quit
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56639), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 305
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\353\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 235}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 239
close(7)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56671), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 309
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\357\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 239}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 243
close(7)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56685), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 289
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\333\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 219}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 223
close(7)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56738), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
brk(0x19fe000)                          = 0x19fe000
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 298
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\344\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 228}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 232
close(7)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56739), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 307
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\355\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 237}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
close(7)                                = 0
close(1)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(56740), sin_addr=inet_addr("127.0.0.1")}, [16]) = 1
fcntl(1, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(1, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(1, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [1 3 6], [], [], NULL)     = 1 (in [1])
read(1, "GET /run?action=scale&jobid=foo&"..., 8192) = 306
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 21069 detached

This is strace result when Imaged was taking 100% CPU

Code: [Select]

# strace -p 31880
Process 31880 attached - interrupt to quit
^[[A^CProcess 31880 detached
Nothing else comming out

I can see as well that when im starting cc panel i have 4 the same imaged processess.
After running reindex command for the first time after restart two of imaged processe are dissapearing.
and when i was doing strace during reindex which you have above one of the 2 precoesses was killed as well but after when reindex is done sometimes this imaged process came back again or sometimes there is no Imaged procesess (wierd?).

Here are strace for other Imaged processess which are disapearing:

Code: [Select]

Process 14026 attached - interrupt to quit
select(1024, [2], [], [], NULL)         = 1 (in [2])
recvmsg(2, 0x97b8c0, 0)                 = -1 EAGAIN (Resource temporarily unavailable)
shutdown(2, 2 /* send and receive */)   = 0
close(2)                                = 0
shutdown(5, 2 /* send and receive */)   = -1 ENOTSOCK (Socket operation on non-socket)
close(5)                                = 0
shutdown(0, 2 /* send and receive */)   = -1 ENOTSOCK (Socket operation on non-socket)
close(0)                                = 0
exit_group(0)                           = ?
Process 14026 detached
---------------------------------

Code: [Select]

Process 14025 attached - interrupt to quit
select(1024, [2], [], [], NULL)         = 1 (in [2])
recvmsg(2, {msg_name(0)=NULL, msg_iov(2)=[{"\350\0\0\0", 4}, {"127.0.0.1;GET /ru n?action=scale&"..., 4097}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOC KET, cmsg_type=SCM_RIGHTS, {6}}, msg_flags=0}, 0) = 236
fcntl(6, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(6, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(6, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
stat("/var/spool/imaged/out/rsz_emb_rmi_welcome_to_80s_years_4e806cf2.jpg", 0x7f ff0d16ecc0) = -1 ENOENT (No such file or directory)
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
access("/var/spool/imaged/in/1362324098-14203-1.jpg", R_OK) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/var/spool/imaged/in/1362324098-14203-1.jpg", {st_mode=S_IFREG|0644, st_si ze=16514, ...}) = 0
stat("/usr/local/centovacast/lib/imlib2/lib/imlib2/loaders/", 0x7fff0d16eb20) =  -1 ENOENT (No such file or directory)
stat("/usr/local/centovacast/lib/imlib2/lib/imlib2/loaders/", 0x7fff0d16ebd0) =  -1 ENOENT (No such file or directory)
open("/var/spool/imaged/in/1362324098-14203-1.jpg", O_RDONLY) = 7
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=16514, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd 62cdd2000
read(7, "\377\330\377\340\0\20JFIF\0\1\1\1\0`\0`\0\0\377\341\32\371Exif\0\0MM".. ., 4096) = 4096
read(7, "\232'Q\2708H\362\261\315\372?\325\257\376\270\207\273\233\254\370GsQ\37 4>f\22>\r\10\330\305"..., 4096) = 4096
read(7, "\313]ZW))Y\304)\25\16\352\325\301~\275\222\35\223\2378hw\3349\17\302|\3 11\313Z\244"..., 4096) = 4096
read(7, "\4kW)d+\n\365\372\245\203\25\247\226=X\243~\224\377\0z\274\370u&2E&=g\2 17"..., 4096) = 4096
read(7, "\3T\261\373=\332\377\0\351\307?M\22}\375\315O\356\373\257\371/\363\377\ 0\307\374W\371q\307\37"..., 4096) = 130
read(7, "", 4096)                       = 0
close(7)                                = 0
munmap(0x7fd62cdd2000, 4096)            = 0
open("/var/spool/imaged/out/rsz_emb_rmi_welcome_to_80s_years_4e806cf2.jpg", O_WR ONLY|O_CREAT|O_TRUNC, 0666) = 7
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
brk(0x9df000)                           = 0x9df000
brk(0x9e1000)                           = 0x9e1000
fstat(7, {st_mode=S_IFREG|0660, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd 62cdd2000
write(7, "\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\333\0C\0\7\5\6\6\6\5 \7"..., 1604) = 1604
brk(0x9dc000)                           = 0x9dc000
close(7)                                = 0
munmap(0x7fd62cdd2000, 4096)            = 0
chmod("/var/spool/imaged/out/rsz_emb_rmi_welcome_to_80s_years_4e806cf2.jpg", 066 0) = 0
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
select(1024, [2 6], [6], [], NULL)      = 2 (in [2], out [6])
brk(0x9ee000)                           = 0x9ee000
recvmsg(2, {msg_name(0)=NULL, msg_iov(2)=[{"\0\0\0\0", 4}, {"\0\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4097}], msg_controllen=0, msg _flags=0}, 0) = 0
shutdown(2, 2 /* send and receive */)   = 0
close(2)                                = 0
write(6, "HTTP/1.0 200 OK\r\nDate: Sun, 03 M"..., 235) = 235
shutdown(5, 2 /* send and receive */)   = -1 ENOTSOCK (Socket operation on non-s ocket)
close(5)                                = 0
shutdown(0, 2 /* send and receive */)   = -1 ENOTSOCK (Socket operation on non-s ocket)
close(0)                                = 0
exit_group(0)                           = ?
Process 14025 detached
------------------------------

Code: [Select]

(......)
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 14648
wait4(-1, 0x7fff0d16ecd0, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = 14648
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14650
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14650
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14651
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14651
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14655
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14655
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14660
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14660
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14685
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14685
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14689
select(1024, [4], [], [], {5, 0})       = ? ERESTARTNOHAND (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], WNOHANG, NULL) = 14689
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
wait4(-1, 0x7fff0d16eb10, WNOHANG, NULL) = -1 ECHILD (No child processes)
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
select(1024, [4], [], [], {5, 0})       = 0 (Timeout)
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=                                                      0x7fd62cdc79d0) = 14690
-----------------------------------

Code: [Select]

Process 14024 attached - interrupt to quit
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(40333), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
brk(0x9ce000)                           = 0x9ce000
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 302
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\350\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 232}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 236
close(7)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(40334), sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(7, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(7, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [3 6 7], [], [], NULL)     = 1 (in [7])
read(7, "GET /run?action=scale&jobid=foo&"..., 8192) = 299
select(1024, [3 6], [1], [], NULL)      = 1 (out [1])
sendmsg(1, {msg_name(0)=NULL, msg_iov(2)=[{"\345\0\0\0", 4}, {"127.0.0.1;GET /run?action=scale&"..., 229}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
close(7)                                = 0
close(1)                                = 0
select(1024, [3 6], [], [], NULL)       = 1 (in [6])
accept(6, {sa_family=AF_INET, sin_port=htons(40336), sin_addr=inet_addr("127.0.0.1")}, [16]) = 1
brk(0x9e5000)                           = 0x9e5000
fcntl(1, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(1, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(1, SOL_SOCKET, SO_SNDBUF, [8192], 4) = 0
setsockopt(1, SOL_SOCKET, SO_RCVBUF, [8192], 4) = 0
select(1024, [1 3 6], [], [], NULL)     = 1 (in [1])
read(1, "GET /run?action=scale&jobid=foo&"..., 8192) = 300
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 14024 detached

I've hope this will help

Hmm, that looks VERY much like a bug I fixed quite some time ago.  In fact, it's identical, and had identical results (100% CPU usage) to the old bug.  I wonder if perhaps somehow the fixes didn't make it into the latest imaged package.

I've rebuilt the package from scratch and pushed it out to the download server -- please update and see if that resolves the problem.  You may also want to make sure you're on the stable branch -- see this sticky for details.