[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: Neon Scribe  XML
Profile for Neon Scribe -> Messages posted by Neon Scribe [50] Go to Page: Previous  1, 2
Author Message
By the way, my Java is currently 1.6.0_34, but I can install 1.7.
The timeout issue may be due to the size of my iTunes library, but it is new behavior as of 5.7.0. It happened before I updated to Mavericks, on the 15/10 build. I'd be happy to pre-test your Java 7 build.
I turned off iTunes integration, but did not restart Jaikoz. I am experiencing extended timeouts doing various operations, such as Auto Correct and Match to Specific Discogs ID. When I try to cancel those operations, items in the menubar remain greyed out for several minutes. Also, the Control-Click (right-click) menus aren't working. The menu pops up, but none of the submenus appear.
25 minutes after I started Jaikoz, it started responding normally to mouse events. I was trying various keyboard shortcuts at the time as well, so I don't know if it was only the passage of time that fixed it.

I will turn off iTunes integration for now, but I can continue to debug this if you like.
This is happening to me. It happened with the 15/10 build on OSX 10.8 and it is still happening with the 19/10 build on OSX 10.9. It is not completely hanging. The mouse does not respond but keyboard shortcuts seem to work. At any rate, I was able to open a folder using Command-O. (The mouse worked within the file dialog for the Open Folder command but not before or after at the top level in Jaikoz.) When I tried it last week with the 15/10 build and OSX 10.8 the mouse eventually started working. I don't know exactly how long it took, but when I came back the next day it was working. I will let you know tomorrow if it works with the 19/10 build on OSX 10.9.
I'm using iTunes to store and play my music collection. I keep the master copy on my Macintosh laptop, where I also use Jaikoz to make the metadata more useful, by cleaning up tags on new music before adding to iTunes as well as sometimes cleaning up parts of the existing collection as needed. (It's too big a job to clean up the entire library at once.)

When the Is Compilation flag is set, iTunes stores its files in a folder named Compilations, instead of under the Album Artist name. This makes sense when there are multiple Track Artists in the compilation, but it is inconvenient when the compilation is a single artist Greatest Hits package, for example. For these cases, I would prefer to turn off the Is Compilation flag. Is there a way to introduce this behavior into Jaikoz as a preference? If the Artist field of all of the tracks of an Album are identical, set the Album Artist field to that value and clear the Is Compilation flag, and maybe the reverse, if any two tracks of an album have Artist fields that do not match, set the Is Compilation flag to true. In that case, if the Album Artist field is blank, set it to "Various". Personally, I would always want the first case to apply, but I can imagine some scenarios where the latter case might not apply, such as an original work (not a compilation) by a single Album Artist where each track lists that artist plus collaborating artists.

Any advice on this issue? My goal is to move album folders out of the Compilations folder and into the folder named for the Album Artist.
Thank you! This helps my workflow.
You mean "Save genres in an iTunes-friendly format"? I just discovered this checkbox. It was not checked, but I just checked it. Was it there before this release? I don't remember seeing it before, but if I had seen it I would have checked it. Could it have gotten unchecked automatically by the update? Anyway, I guess that should fix it.
I'm having this problem with 4.6.2 on OS X Mountain Lion. I had 150 or so tracks I was editing in Jaikoz, setting Genres on some of them. When I imported them into iTunes (the latest version on Mountain Lion) all the genres that had numeric equivalents showed up as numbers instead of names, e.g. Folk-Rock became 81, Progressive Rock became 92, Rock became 17, etc. My preferences are set to Always Delete V1 tags, Always Write Tag, v23.
I solved the problem. It turns out that I downloaded the new version of Jaikoz but I unzipped an old version from my Downloads directory. After I deleted all the jaikoz-linux.zip files and removed the ~/Jaikoz directory, re-downloaded jaikoz-linux.zip and re-installed from scratch it seems to work. The first time I launched Jaikoz exited with a database connection error. The second time I launched I couldn't get any menus to work. That may have been a problem with my X11 server, not with Jaikoz per se. The third time it started fine and I was able to open a folder.

One suggestion based on this experience: it would be nice if the file name of Jaikoz zip archive included the version number. The problem I ran into was having several jaikoz-linux.zip(n) files in my Downloads directory.
I just downloaded and installed 4.5.4 on Linux. When I start it complains that my license is invalid and quits. I retrieved my license.jai and put it in Jaikoz/Prefs. This time it prompts for my license file. After loading the file it complains about the license being invalid again and then quits again.
I should probably turn this into a separate top level wishlist topic, but I'll raise it here since it came up in this context. I find myself wanting some kind of "soft delete" capability. That is, I want to mark a set of fields as replaceable as if they had been deleted, without actually deleting them. If any data becomes available from another source, they should be replaced, otherwise they should survive. This "replaceable" condition should last until I quit or save. This would simplify some of the operations I've been trying to do. You could mark those fields with a new color to indicate their status.

I realize this is a significant request, but I think it might be of general interest.
And I realize that what I'm requesting would really only make it a little more convenient to use. The more challenging problem is that it is difficult to find the original date. I find myself browsing for vinyl releases, copying and pasting Musicbrainz and Discogs IDs into Jaikoz and sometimes forcing an override on an elapsed time mismatch. Then I have to do a little dance to change values: delete fields first then match to specific ID, or match first then delete fields then Remote Correct->Update Metadata. Deleting fields causes tracks to get reordered, which sometimes makes the track I was working on disappear from my current view.
Yes, what you describe works fine. What I was hoping for is that I would not have to clear out the existing date in order to have it changed to an earlier date.
Yes. A collector might care about the release date, but a listener cares almost exclusively about the recording date. Unfortunately that information can be hard to find. The oldest available release date is a good substitute for recording date. I've had some luck manually forcing Jaikoz to use the original vinyl release to get that, but Auto Correct seldom finds it. I would like to have a preference setting for using the earliest available date. If there are multiple matches in Musicbrainz I want to use the earliest date even if a later release is a better match. If the date on the track before Jaikoz intervenes is earlier then i want to keep that date. If Jaikoz finds an earlier date then I want to replace it. if Musicbrainz has the original recording date that is the gold standard, but few tracks have that information available.
Setting all four options still isn't exactly what I want. I'm working with a large collection, some of which have years set manually to the recording date and some of which have years set automatically to CD release year. So in fact I would like an option that more aggressively uses the earliest available year.
Matching to release 583696 on Discogs caused this incorrect undoing of Proper Name & Group, The in the artist name, so that

Joni Mitchell & L.A. Express, The

became

The Joni Mitchell & L.A. Express

instead of

Joni Mitchell & The L.A. Express
In some cases I have carefully entered the original recording date on songs in my library. In other cases I may not have worked as hard to find that date, in which case I would like to Do Extra Searches and Put Original Year into Year field. Basically what I want is the earliest available date, whether it is one I have manually entered or one that came from an authority such as Musicbrainz or Discogs.

My observation is that Autocorrect finds those early dates about 60 to 80 percent of the time. Often Jaikoz refuses to match early releases for seemingly good reasons, such as mismatches in track length. I always override those decisions when forcing a match to a specific Discogs or Musicbrainz release.
I'm not interested in release dates in my music library. I want to label tracks with recording dates if at all possible. Basically, I always want the earliest possible date to apply. I would like to have a preference in Jaikoz to reflect my preference: when correcting release dates, always use the earliest date available, even if an authority claims to have a more accurate date.
I am also seeing the "Track Total" field getting cleared. I am doing a full Autocorrect Songs, but I had already used up my quota of 5001 queries to Discogs, so that may have affected the results differently than the other user's report. I tested this on a collection of 56 MP3 files, all of which were purchased from the Amazon MP3 store. MB Unique Ids were found for 48 of them, and the Track Total field was cleared on all 48. The other 8 did not have MB Unique Ids and still had their Track Total fields.
 
Profile for Neon Scribe -> Messages posted by Neon Scribe [50] Go to Page: Previous  1, 2
Go to:   
Powered by JForum 2.1.6 © JForum Team