Jaikoz- Discussion Forum

Works fine now. Thanks for the always fast response.

I am getting this for a lot of entries, but don't see the null part of the message. It's happening on plain mp3 files for me. And these aren't strange tracks. For example, on mainstream U2 releases I get it.

From the log:

Code:

 09/08/2008 09.55.26:com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerReadThread:analyse:SEVERE: There was a problem submitting a query to MusicBrainz for Record Number 26 with filename U2-Rattle And Hum-08-Silver And Gold Live.mp3: {2}
 java.lang.NullPointerException
 	at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedNumberOfTracksInAlbum(MusicBrainzRESTQuery.java:1707)
 	at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedAlbum(MusicBrainzRESTQuery.java:1813)
 	at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedScore(MusicBrainzRESTQuery.java:2067)
 	at com.jthink.jaikoz.manipulate.musicbrainzhelper.TrackWithUnnormalizationScore.<init>(TrackWithUnnormalizationScore.java:24)
 	at com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerReadThread.analyse(ManualCorrectFromMusicBrainz.java:354)
 	at com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerThread.run(ManualCorrectFromMusicBrainz.java:290)

Just for the record, my experience with this problem went away. I know I had closed Jaikoz and reopened it without solving the problem initially, but I am not experiencing it now (without any updates). Maybe I rebooted...

This was on OS X, by the way.

Hi,

I can no longer change the field for the Base Folder in 2.3.1 as I could before.

Essentially, I want to change the Base Folder for my loaded files (I have the "MB ID Exists" filter enabled) to move them.

thanks

When I do a manual match on a track that already has a MBID set and select an entry with a different MBID, Jaikoz is not replacing the existing MBID with the new one.

Is anyone else seeing that happen?

I think I covered my view on the Manual lookup option in the other thread along with a gui mockup so won't rehash any of that other than to say that the main shortcoming I have found in the Manual Match process is that I often end up matching PUIDs from different release entries in the MB database.

Granted, a lot of times this is because there are duplicates in the MB database, but at least showing the MB Release Id would allow the user to easily match up to the same release entries.

The other thread, by the way, is at http://www.jthink.net/jaikozforum/posts/list/174.page.

Minor bug in that when you do a Find and Replace, the drop down list in the dialog window that lets you limit your search to specific column shows each column name twice.

I also had my Jaikoz freeze when I tried to execute the find and replace, but I have not re-tested to see if that was a recurring issue.

For what it is worth, I am successfully running the latest release on 10.4.10 (actually on 2 iMacs - one a PPC and one an Intel in the house).

When you run this report, it now reports alls tracks missing album from all albums.

I think you guys stumbled upon a different bug.

Regarding what I experienced, I am able to consistently reproduce the problem I initially mentioned in this thread.

Create a folder with multiple sub folders containing tracks. Open Jaikoz and do a File - Add Files of this top folder. Make sure you include sub folders in the scan.

Jaikoz will open all the files just fine. Now do a File - Close Files. Everything closes fine.

Without exiting Jaikoz, do an Add Files again and choose only one of the sub folders. Jaikoz will report that you already have the parent folder open and that you cannot open files twice even though you closed the files.

Is this a bug?

Is there a limitation of the v2.2 format in that only the MB track UID and MusicIP ID are saved?

If I tag everything, save and then re-open the files it does not have the MB ID tags (artist, release) anymore.

My ultimate goal would be to get access to the internal IDs, especially from other track records on the same album, in a more comprehensive way on the screen to help better select the right MB ID for the track.

I'm not so sure I agree that casual users wouldn't also benefit from this. While I cannot obviously speak for anyone but myself, the main reason I bet most people select Jaikoz over other tagging software is the thorough MusicIP and MusicBrainz integration. So being sure to match the IDs properly would be of use for many users, I think.

Regardless, I would see it as an improved replacement for the Manual Tag from MB function. It has all the same information (adding the additional columns like track #, length, etc is easy enough with that layout) plus the benefit of better album ID matching.

I also think this interface could be an improvement for usability in regards to the batch queries. It becomes less important to do large batches if you basically have a queue of 20 or 30 queries in memory and the program queries ahead of the user's involvement with selecting tracks.

I agree that there needs to be an improved way to copy and paste certain fields across records. For example, all the fields that show under the MusicBrainz tab in the detail view should be settable as a column for easy copy and paste. I think Paul is reworking that if I have read some other postings correctly. This would basically let you set the ASIN field as a column and then copy and paste down to multiple records.

In the meantime, I actually just save the artwork as a jpg on my machine then add it to the first track. Then I can copy and paste the artwork down to multiple tracks. Agreed it is an additional step and leaves you with the jpg on your machine, but overall workable for now.

I have noticed that quite often the first track of an album which is already marked as track "1" will fail in the MB lookup but the rest of the tracks proceed fine. It happens enough that it makes me suspect there might be a small bug where this happens under very limited circumstances.

Is anyone else seeing this kind of behavior? Or is it purely my imagination?

There must be something uncommon in the JPEGs that show this problem. I "solved" the problem by opening them in the OS X Preview function and then just doing a save. After that, I could add them without the palette corruption.

I reattached the exact same JPEG as before but after I opened it and saved it.