INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Replace, Move, Copy … (Update database…) breaks existing CUE splitting  (Read 634 times)

Library Eye

  • Junior Woodchuck
  • **
  • Posts: 63

I am encountering issue noted over in old Windows version…
https://yabb.jriver.com/interact/index.php?topic=126461.0

…which I recall I've seen before, going between disk drives— Mac to Mac or Mac to Linux.

This issue continues, and is posing a real problem for me. Well, at least it persists as of MediaCenter 29; I'm a "Master License" holder, because macOS & Linux— don't use it in Windows, which is obviously the program it was devised for, I realize, and I primarily use it on macOS. So I've stopped buying every update, 'cause issues with Mac version just seem to persist, while new features don't much materialize for it either, nothing I really need. So, I've been planning to upgrade when 32 rolls around, then 34, etc— every other version.

I moved music library from one external HDD to a faster external HDD; same macOS. I'm using the good ol' handy "Update database… new location… no… move or copy" option of this great feature.

No matter what I try — and wasted a lot of time so far on this — looks like all cue-derived albums split from an associated single audio file are now broken, only showing first track.

Taking quick look at smart playlist of whole slew of missing files, I can see some related paths are now totally wrong as well, leaving out part of path and instead seeing non-existent path from inside of cue sheet data— and this is with no so-called special characters in play (of which, in macOS going back forever, there are practically none— but I mean even no restricted Windows / SMB naming forbidden characters)

Only way to keep library working with those previously properly split albums is to rename new HDD after the previous HDD, but seeing as how that old HDD is still in use for other stuff my other computing needs point to (other apps; Time Machine; Carbon Copy Cloner; etc) that's gonna cause other headaches.

Anyone know if this issue has been resolved in current version? If so, I may just hold off and keep using slower HDD for music drive until I upgrade to JRiver 32.

thanks
Logged

Library Eye

  • Junior Woodchuck
  • **
  • Posts: 63

I've partly gotten around this by reverting to library backup, hiding both old and new HDD, and then manually editing, via TextEdit, the field (filename).jmd file in the JRiver library folder. But it's a hassle.

But I am seeing other issue unrelated to cue sheet— happening with regular individual files, too. Name of my old HDD included a two digit number. For some JRiver reason, this is resulting in any track whose track number happens to match that two digit number either being duplicated or missing or disappearing upon updating library no matter what method I take. SO then I had to use Replace, Move, Copy … (Update database…) — before mounting the external HDD, so as to avoid getting dupes — to fix fake path for every single song which has track number which matches the two digit number I have always had in name of old HDD.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72549
  • Where did I put my teeth?

You might try MC31.  A lot of work has been done on the Mac version.  Also on the back slash and forward slash problems when migrating.

Would find and replace help?  It's an MC Tool.
Logged

Library Eye

  • Junior Woodchuck
  • **
  • Posts: 63

You might try MC31.  A lot of work has been done on the Mac version.  Also on the back slash and forward slash problems when migrating.

Would find and replace help?  It's an MC Tool.

Thank you Jim.

 I am not migrating between operating systems, so the slashes aren't a problem. It was only after Replace, Move, Copy … (Update database…) broke all single-file associated cue sheets, I thought I'd try the manual renaming. Then I noticed the problem with JRiver getting misdirected by numeric beginning of my old hard drive's name (treating like the start of new paths, it seems {??}**, but only after switching disks) with any kind of file— and that I was able to get around with Replace, Move, Copy … (Update database…) tool. Now, every single track of that number is wrongly showing as never having been played / because seen as newly imported, but at least (fas as I have seen) none vanished this time, nor disappeared from playlists they're in, nor got duplicated (because I did the Replace, Move, Copy … (Update database…) before mounting the Auto Import location).

So as of now, think I will consider it done. But if I find it's still not right, I will revert and try Find and Replace where appropriate.

I look forward to upgrading. May go for 31 — glad to hear about the Mac work on it!!

** Is this a potential problem for any users, any OS? I just happened to name my old HDD after its TB size, so it started with a two digit number, which upon switching HDDs, MC decided must mean every single track of that number was supposed to go into a special directory starting with same digit.
Logged

Library Eye

  • Junior Woodchuck
  • **
  • Posts: 63

Still resolving this, very slowly. Find and Replace cannot help because it does not have option to change field I now know I need to change. The problems moving music to new HDD and retaining JRiver library have been manifold, so sharing below in case anyone else ever has misfortune of same peculiar circumstances, or just to note a practice to avoid (numeric characters in volume name).

• All, or most, single-audio-album-files split by cue sheets failed / were not properly retained when I used Replace, Move, Copy to route library to new HDD; all that was left was a single file, no splitting. I have seen this before, and other users noted in past— might not be issue for someone starting a new library now and moving later. Dunno. Seems likely though. Anyhow, I got past this by restoring library, then manually editing, in TextEdit, the "field (filename).jmd" file in the JRiver library folder.

• However, I then saw, though everything was happily in place (each file, from cue or not, in any playlist where it had been, and retaining play counts, etc…) that once an auto import was completed, a whole bunch of tracks went missing from any playlist they were in, and had play counts reset, and ended up in "Recently Imported" smartlist like they were new. Not just files from cue sheets… any files. Any files that were… track number 10! So, I then realized, snooping around the field (filename).jmd file in the JRiver library folder and other settings files, that …

• Because my old external hard drive's name started with the number 10, JRiver all along has been seeing Volumes/10restofHDDname and erroneously creating extra directories for any track number 10, making false paths in the library, and now that I was migrating library to point to to new HDD, with different name, all track number 10 files (any format) were vanishing and being reimported, lost from playlist, and sometimes replaced by track number 1 from same album. What a mess.

• So, I restore again. I changed main new path again in the field (filename).jmd file in the JRiver library folder, as well as in images jmd file, etc, and went through and got rid of all the extra paths made for all track 10s. This fixed all the non-cue sheet related files. Along the way, false volume showing 10 at start of (new!) HDD name now showed up in the Files interface. I meticulously deleted dupes not in there, which is where the original files temporarily resided, and like other steps had to do this with actual files / HDD not mounted so as to not initiate auto import. but…

• once an auto import was completed, all track number 10 songs from cue sheet associated albums were vanishing as before. So, I restored to most recent previous point and saw this is because all the cue-sheet-associated track number 10 songs were missing the semicolon and number at end, as in
FileName.extension;10
they were supposed to have, as seen when viewed as Filename (name) because unlike
FileName.extension;1
thru
FileName.extension;11
etc
since JRiver had made false paths all along, all the track 10 songs from split cue files were wrongly seen as the one and only file associated with cue sheet, and therefore Filename (name) read as simply
FileName.extension
for all track 10 songs, and so upon autoimport, those would vanish, a properly named ";10" Filename (name) would appear, but would not know to go into playlists, retain play counts, or any other existing settings.

So then…
• I needed to see all my track 10 songs from split cue sheets.

No smart playlist option for that, so I finally realized a smart playlist showing all track 10s with stipulation

Playback Range » is not <empty>

would show those, since split cue sheets rely on Playback Range for track durations.

However, as noted above, Find and Replace cannot help because Filename (name) unfortunately is not a field it can change.

So now I am manually going thru all those files (only ones in a playlist, or with play count ≠ zero — because I don't care if others get reimported as if new) as viewed in smart playlist and adding

;10

to end of Filename (name)
of each

So, I would say—— don't ever start (or end?) name of the HDD with numeric characters, if that's where you're housing your JRiver music.
Logged
Pages: [1]   Go Up