Jaikoz- Discussion Forum

cpicton wrote:

OK - that makes sense. I have checked and some do not contain PUIDs.

As my first run through the files, I want to only move those with valid PUIDs. Can I set up a filter for this?

No filter is available for this,yet.

Actually what your saying is you are much more confident about the records with Puids than those without. You could start again and this time set 'MusicBrainz Settings/Minimum Rating Required if MetaMatchOnly' to be 100, so for records without a Puid it will only do a MusicBrainz match if it gets a good meta data match.

cpicton wrote:

I am trying to match quite a few files based on musicip puid.

I am guessing the following columns
TRM = Unique File Id
PUID = User Defined Text Info

I have told it to retrieve PUIDs, and autocorrect from musicbrainz

On the output, I have a few duplicates on Unique File Id, but very few duplicates for User Defined Text Info, but the updated tags appear to be based on the TRM (which have duplicates), and not the PUID (which has fewer duplicates)

Is there a way to autocorrect tags from PUID, as opposed to TRM?

Hi, TRMs are not used at all anymore. PUID is the MusicIP value within the User Defined Text Info (it also holds other values). Unique File id is the MusicBrainzId

Are the duplicates valid, is it identifying duplicate tracks in your collection?

Puids are created when you run retrieve acoustic ids whereas UniqueFileIds are created when you tag from MusicBrainz. I am wondering if you have less duplicates on the User Defined Text Info because some do not contain a puid, double click on the count to check, or look at your jaikozuser.log for information on how many acoustic ids were created. If you dont have an acoustic id then tag from musicbrainz is based purely on the metadata.

Anonymous wrote:

I still can't reproduce the prior bad behavior, but clicking "Finish" while Jaikoz is still loading leaves the app in a weird state. For example, if I Close Files and then try to immediately reload the same folder with 176 tracks after interrupting the first folder load, it refuses, saying some of the same files are already loaded -- even though I did "Close files" between loads, and the bottom status bar reported "0 files loaded" after I Closed Files.

I think things are wrong with the load, close, "Finish" routines. A simple test like I've tried to report above leaves the app in an invalid state. That could have resulted in this mishandling of file contents and file names.
I hope that helps.

Thanks, I will review the Finish code maybe something is not being initilized properly, although I cant see the error so far.

There does seem to be bug with Close Files whereby files that are closed are not removed from the list of open folders used by 'Add Files' and 'Add Folders', I think this must be the problem you encountered. You wouldnt have hit the problem if you had reopened the files using the 'Open Folder' button, Ill get this fixed though this in itself wouldnt cause the invalid state.

I note you've added a review to download.com, maybe you would consider toning it down a little - it seems rather harsh.

Ive checked the code but have not been able to find a cause of this problem

From the log this is what seems to have happened:

Loaded 176 files, made some modification and then elected to save changes, four files were saved without any errors issued. Then some more changes made including changes to the files that had just been saved, and save was performed again. When saving Jaikoz reopens the corresponding file on the filesystem and then save its with the new changes, but it was unable to find the files that had previously been saved, however it did save 8 more files that had been modified. Then another attempt was made to save changes and this time it was unable to find any of the 12 files that had been saved.

Files are not being deleted randomly, but it appears that in this case the files are disappearing despite the fact that Jaikoz make no attempt to delete any files, Delete is only called in one circumstance when the user has marked a file for deletion but there is no evidence of this from the logs.

Well, in fact, it had deleted half dozen random files, and then renamed others to the names of the deleted files. Then it reported being unable to load the files it renamed (it could no longer find the original-named files).

I dont quite understand this line, you seem to be saying the files do not exist, but have been replaced by others files with the same name:how do you know that isnt the original file.

I am making some changes so that additional information is added to the log files and console but I am at a complete loss to how this has happened. I can simulate the error by saving the files in Jaikoz, then externally using File Explorer on another application removing the files from the folder then if I tried to save the changes again the error you describe would occur. Now Im sure you didnt fo this interactively, but can you think of any application that might be automtically doing something to files once they have been updated ?

ozone wrote:

There is already a find option, but how about a replace option too?

I agree, I had hoped to add a Replace and a Find All in the last release but had a couple of issues, should be in next release.

ozone wrote:

Also, have you ever tried Magic File Renamer? The reason I bring it up is I was curious if you were considering building that type of functionality into Jaikoz?

Thanks for heads up, Ive never heard of it and it looks like it is no longer being developed. I expect Jaikoz will have most of this functionality - I am certainly looking at allowing users to use powerful regular expressions for various tasks.

ozone wrote:

The result will be "Tom Cloud Ft\. Tiff Lacey"

oops i didnt notice the '.', same problem as '&' and already fixed ready for next releease.

ozone wrote:

By the way, on another note, some ascii characters don't show up properly in the Tags; rather, they show up as squares. Do you know what I'm talking about? Maybe you already know about it and are working on it, but if not I can screenie it.

Squares are actually shown when the character is a unicode character that cannot be displayed such as Bell (\u0007) or Null (\u0000). If these values reside in Columns with Local Correcters such as Artist or Album they will be removed as long as you have 'Remove Undisplayable Characters' ticked in your AutoFormat settings for that column. If they are in another column, for now you would have to delete them manully.

If you think you have a case where there are actually values that should be displayed please send me more details.

Thanks, popups are only meant to show the first 30 errors to stop this ort of thing happening, but something must have slipped through here.

Could send me your jaikozuser0-0.log and jaikozdebug0-0.log so I can track this down.

ozone wrote:

In the replacement list I had the word "and" replaced to "&". However when Jaikoz does this, it replaces "and" with "\&".

Thanks, Ive replicated this problem it occurs because '&' is a special character in Javas' pattern matching language and has sometimes has to be 'escaped' with a '\' , but in this case it should not have been. Ill fix this.

ozone wrote:

I
This also happens for example when I told it to replace "feat" with "ft."
It ends up replacing "feat" with "ft\."
Why is it doing this?

But I havent been able to replicate this case, could you double check and provide the full text being modified, and the full contents of your word replacer, you can send screenshots instead if that is easier.

paul

Good idea

, Ive added it to the list.

please try out the simple installer (just unzip and run) released today

A new version was released today,Importantly retrieve acoustic for Intel Macs is now available, there is a local artwork correcter to help with your cover art and there is a simple installer for Windows Vista

Please take a look at http://www.jthink.net/jaikoz/jsp/news/start.jsp for full details.

Pleased to tell you that the new release of Jaikoz now supports retrieving acoustic ids on Intel macs - and perfomrnace has been improved or PPC macs, sorry for the delay

Anonymous wrote:

It actually seems that the "Add File" function may have a problem, which may have kicked off my other problems. This file reported as unrecognizable, is in fact a valid mp3 (at least according to winamp, dbpoweramp, helium mm & similar).

This problem has been fixed, in Jaikoz 1.6 released today

I'm suprised you our still not having much luck. Jaikoz v1.5 performs much better for Linux than v1.4.1, however I don't think it is still quite as accurate as the Windows version, but unfortunately the code for generating acoustic ids is not written by me, but provided by MusicIP so i dont know the full details of the differences, I have asked MusicIP if they can give me any more information on the differences.

Could you try running Jaikoz on Windows against these files as a test/workaround ?

Paul

Jeb wrote:

Seems that the "." is not recognized as word separator. So then

I can see why you came to this conclusion but . is recognised as a word seperator but the word seperator is only used for comparing values from different records during the AutoMatch process it is not used for formatting the output (AutoFormat)

Jeb wrote:

Any suggestions? Seems like we need one more mode for replacing/removing a free form string or add removing .mp3 as an acceptable rule for the default title correction.

Yes, ive tried to get round this but I cant, either we need to use a Word Seperator for autoformatting as well so that you can define word boundaries OR as you suggested allow replacing/removing a free form string.

I think the second option would be useful to more users, and would fit best as a replace option in the find popup, what do yout think ?