[Logo] Jaikoz and SongKong Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: christian  XML
Profile for christian -> Messages posted by christian [16]
Author Message
Just a wild thought but perhaps the Mac is caching web hits?

Paul did make a change to blast through web caches earlier this year.

If you had an error on a query then the cache would continue to return the same error thus if MusicIP had a problem which created the error but would be solved on a retry then you wouldn't see the correct answer.

I haven't looked at the history on this particular issue so it really is just a WAG.


bugmenot wrote:
Congratulations on the support front Paul! These forums suggest you are incredibly dedicated to this project. Hopefully I am experiencing one-off problems.  
As a Jaikoz user myself, I think you just happened to hit a bad patch of issues releated to the 2.8.x releases. Jaikoz has otherwise been quite good.

There is no doubt it would be frustrating and given you entered at that point in time, I can understand the opinion you formed. I can assure you this is not typical. I hope your experiences improve from here.

Christian
Well in my opinion I find the product to justify the price. I looked at all the alternatives I could find including free and pay. Jaikoz is very good value for money. I've had issues but compared to anything else out there it has amazing functionality.

If you wish the open source version, there is MB's piccard. It's free and it is fine but not nearly as good as Jaikoz.

As for MB. My only real issue with it is that Genre is all over the map. But with Jaikoz, I simply look to Discogs which is a little more sensible. Other aspects of MB have worked quite well for me.

As for resource demands. I think the comment is fair. It is an area for improvement for large collections.

Christian
Just to confirm 2.8.4 did the trick. Confirmed on the most problematic sets I had with over 7500 files.

I think there is still something wrong with MB as it kicks up quite a few 503s. One for about every 250 files.

It would be good to see if it resolved other people's problems too.

Christian

paultaylor wrote:
Ive added the following for all url connections
 


ok. if you want me to test it ahead of release, feel free to send a patch via email. You should have my email address.
I set the negative_ttl=0 on squid.

Just ran >5000 files and it completely successfully.

MB returned 503 a number of times and the most retried I needed was 2.

I think I figured it out!

A number of users are going through an http proxy and cache either in their own environment or their ISP's environment.

When MB fails with 503 (service unavailable) the proxy caches this as a "negative hit" and gives it a Time To Live (TTL) before it will pass a new request. In my case I use squid which defaults to a TTL of 5 minutes.

So once you hit a 503, the cache will continue to fail your requests within the TTL window.

You should be able to override this in the HTTP request within Jaikoz as in your case your subsequent requests are in fact meant to bypass any caches.

I verified this by waiting for a 503 with retries then disabled the proxy while it was retrying which then allowed Jaikoz to proceed properly.

If I disable the proxy all together and run Jaikoz I get the occasional MB busy message but it works fine on the first retry.

Given many people won't have control over their cache and proxy, it is best to have Jaikoz force the proxy not to cache.

If you wish, I can test a fix as I do have control on my cache.

Christian
Paul,
sorry, no joy here. Issue still exists with BM Server busy.

Here is the spacing between requests that failed:
Feb 10, 2009 12:15:24 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 1
Feb 10, 2009 12:15:25 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 2
Feb 10, 2009 12:15:27 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 3
Feb 10, 2009 12:15:30 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 4
Feb 10, 2009 12:15:34 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 5
Feb 10, 2009 12:15:39 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 6
Feb 10, 2009 12:15:45 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 7
Feb 10, 2009 12:15:52 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 8
Feb 10, 2009 12:16:00 AM: WARNING: MiniProcess 0 having problems connecting to MusicBrainz Service, may be down or just busy, retry attempt 9

I thought there were supposed to have a more spaced out starting interval. This starts at 1 second and then increments by one (your new algo I guess). But sometimes when it failed in the past requests were spaced by 5 sec or 3 sec or 7 sec (has always done this). Is this design intent to make initial retries a random starting interval?

I still think the issue is environmental or an uninitialized (or corrupted) variable. It can fail consitantly on a specific file in one period of time but allowing it to sit for say an hour and then retrying will often have that file succeed. Other files around it have no problem at either point in time.

Is there a simple way to trace the exact request and response between Jaikoz and MB? This would at least allow us to isolate whether it is local or an MB interaction.

Christian
At some point in the process there may have been a network issue to the lyrics server and it got marked off line:
SEVERE: Lyrics service already marked unavailable

In the past I have had to exit Jaikoz and restart it to clear this but this means I have to start from the beginning on my tagging.

Is there a way to force this to retry again?

It doesn't seem to timeout to mark online but I ma not be waiting long enough.

Christian
Interestingly this gets rid of my issue with clicking "Is Compilation" throwing an error. So the issue is either an environmental issue on my side (I have tried to re-install Sun's Java) or something with the latest Sun update to Java.

However, I was hoping it would solve the Musicbrainz timeout issues but it did not so I'm guessing the JVM isn't the issue.

Christian
Paul,
Just upgraded to 2.8.1

Now when ever I select the field "Is Compilation" I get a an error window saying:

"Unexpect Problem with Jaikoz please report problem to support@jthink.net"

"java.lang.Boolean cannot be cast to com.jthink.jaikoz.celldata.Cell"

[OK]

I can still cut and paste in the field but any time I select it I get the above error.

Excerpt from the console:
Jan 16, 2009 11:57:42 PM: SEVERE: Unexpected Problem with Jaikoz please report problem to support@jthink.net
Jan 16, 2009 11:57:42 PM: SEVERE: java.lang.Boolean cannot be cast to com.jthink.jaikoz.celldata.Cell


Hi Paul,
Normally I don't do this but I was inspired with a particular album to try several Genres (I just couldn't pin it). I added these to the first track and then did a copy/paste for the others. However, it only copied the first entry.

A bug perhaps?

Christian

Is this random in nature?

If I get this failure, simply retrying will allow it to go further before perhaps failing again. Sometimes with a retry and will then fail around where it failed before.

However, with persistence, I can get it to complete.

I have been considering a downgrade to 2.6.0 just to remove the issues. Is this safe with the existing preference file or should I remove that and redo my settings.

Is this problem in 2.6.0 as well. I don't recall seeing it before.

Christian

paultaylor wrote:
Its in the popup menu (near the bottom) and applies to all selected files.

Do people have problems with the popup menu, I could add the option to the File menu but if I did and it was selected would you expect it to apply ALL SELECTED files or ALL files 


I must be missing something obvious. Where is this? When I save, I don't get a pop up and I see no other option to allow the save and move.

Christian
Understood and not unexpected. I actually do have this working but it is obviously throttled.

For reference what I have done is installed the VMWare image available from MusicBrainz which is intended to run on vmplayer. The image is a little stale (including the install instructions) so required some mods to make sure the software and database were the latest; which they are now.

A simple way to verify that it is a local address is if it is in the same subnet. Of course this could be defeated through a proxy but my guess is that it is almost as much effort as setting up the vmware image.

A better way may be for MusicBrainz to identify the current rate limit and thus have the local server programmed to respond with "fast".

I think it would also be relatively simple to keep the vmware image up to date with the latest svn release by the release team and then automate the database retrieval. If you found it useful, you could do it. It really is as simple as keeping the VM up to date and then saving the current environment.

For the average home user running windows, it could be a simple process then of:
- installing VMWare player (or server) on their desktop (free);
- loading the MusicBrainz VM (delivered as an image);
- update the database to current;
- point Jaikoz to the local server.

Cheers,

Christian
I've set up a current image of MusicBrainz database on a vmware on one of my servers with the desire to increase the query speed with Audio Tagger.

Assuming it is possible, what setting do I need to change to allow the queries to run at full speed rather than the default used to throttle musicbrainz.org requests?

Christian
 
Profile for christian -> Messages posted by christian [16]
Go to:   
Powered by JForum 2.1.6 © JForum Team