Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JRod]

Hi, using JRiver 27.0.35. I noticed that in a multi-disk album, JRiver is renumbering my tracks sequentially, say from 1 to 50 instead of following the tag information for each disk. it should display disk # then track # for each disk in the proper order but it just does straight sequential numbering on its own.  I checked the tag information and the disk and track numbers are correct but JRiver wants to renumber the songs its own way. The only thing that does look right is that the disk numbers are correct and sorted in the proper order. I don't understand why such a simple thing is so hard to achieve. I've tried sorting this way and that way but haven't found how to fix this.  Anyone have any ideas?

[wer]

I can try and help you figure out what the situation is. Please provide (post) a screenshot, showing the entire window, so that I can see what is actually happening.  Please ensure that the Track # and Disc # columns are visible in the file list in the screenshot.

[JRod]

Hi, Let me give an update. I got an idea and did the "update library from tag information and it straightened out.  now the track numbers are correct.  I'm not sure I understand why I had to do it in the first place.  if the tag information is correct to begin with, why did MC 27 decide to display its own track numbering? In case it matters, the library is up on my Synology NAS running Minimserver .8. I never have any problems with connecting or playing the tracks.  Just this weird thing that came up recently.  I don't remember having this issue with previous versions of MC.  OK, I just tried closing MC and reopening. the problem is back. I had to do the update from tag information again so it looks like an ongoing issue.  And, yes, I do have the track and disk number field columns showing. 

[wer]

Please read my previous post.

[JRod]

Here's an attachment of a screen shot of one such album. Not sure I did it right as I've never done it before.

[wer]

You did it fine.  I should have said have the [Filename] column showing too, so we could compare, but let's start here.

So the tracks I see look like they're in order, but a few are missing (some bonus tracks at the end of disc 1).  There is more than one version of this album, so I must also wonder if your tags were correct to begin with. Tagging retrieval services contain data input by other users, and users often input garbage, or the album might have been matched wrong.

Since these look correct, do you think they're wrong, or do you think they're showing correctly now, but will spontaneously change to wrong later?

Let me see another screenshot when the track #s are showing incorrectly, and include the filename column.

Do you have "Run Auto-import in background" turned on? It's in Options->Library & Folders.

Another thing you can check is if you open the tag window for a track (click the tag button in the lower left corner) then you can expand the Tag Dump pane at the bottom. This will show you the tags MC sees in the file. Compare the TRACKNUMBER entry to what you see in MC.

Finally, when you have the tags showing correctly in MC, you can do an "update tags from library" and this will re-write the tags correctly. Some files just have corrupted tags.

MC does not make up its own numbering. I have never seen MC change the tag numbers to deviate from what's in the file without user intervention.

If tags are missing or corrupted in the file, when you import the files MC might try to derive the information from the file name.  Do your file names contain track numbers that conflict with the tags in the file?  Again, look at that tag dump pane to see.

[JRod]

OK, I'll do another screen capture with the filenames if you think it would help you figure it out. What I'm trying to convey is that JRiver doesn't follow the tag info in the tracks.  if you look at where it goes to disk 2 JRiver should be going back to the correct file numbering for that disk (the tags have been confirmed to be correct). instead, JRiver just continues to number these files as if it was still disk 1 but with progressively higher track numbers.  There are some files missing in this disk perhaps but that shouldn't matter.  JRiver should still number the tracks according to the tag information and instead, it goes to its own numbering scheme whatever that may be. This isn't the only multi-disk album that JRiver does this so I highly doubt that my whole collection is somehow corrupted. I don't have this problem with any other app I use to access this library.   I'm attaching 2 screen captures, one how it looks after I execute "Update Library from tags", the second one shows the full file names.

[JRod]

Opps, here's the right one with the proper file numbering after executing the command

[wer]

Well, what you call "the second screen capture" is the exact same image as the first one you posted.  It still doesn't show anything wrong.  After your "oops" post, the new image still has correct track numbers, as I think you pointed out.

Your screenshot in the middle doesn't show any track numbers, wrong or otherwise, but it does show that you have added the files to your library from a web server, using an http:// url.  Which means MC can't write to them.  Why are you doing that?  Why not add the files to MC from an accessible folder, on a local or network drive?

You keep saying MC "goes to its own numbering scheme" but you haven't shown me that.  You never shown any incorrect numbering. You say the "tags have been confirmed" but how?  I have to wonder about these things, because you still haven't shown me an actual numbering problem.

But back to what I said in the 2nd paragraph: not sure why you're adding files via http links. I suppose that could cause problems. I've never done it, and I don't recommend you do it.

Minimserver is what runs on a Synology NAS.  I don't know what it might be doing with the tags as it serves them through HTTP. But that's not the proper way to add files to the library.  Try adding them directly as files using a network share, and see if you still have problems.

[JRod]

I'm not sure why you're not seeing it. must be the confusion of the multiple images I've uploaded.  OK, see where going down the list of tracks, the list goes onto the tracks from the second disk?  Instead of starting with the proper track number for disk 2, it continues to number the tracks picking up from the last track on disk 1. it goes from track number 11 of disk 1 to track 12, and so on, ignoring what the actual track number is for disk 2.  I don't understand how you can't see that. Now you're going on with why I'm doing what I'm doing and how its wrong. I access this library from other devices and not all of them run JRiver.  It's a good way of having a central library where management is simplified instead of having to copy files all over the place every time I get new music.  You know if the JRiver remote app was a bit more capable and I could use it to access my library remotely when I'm out maybe I could just use JRiver and drop the rest but, unfortunately, that's not the case.   

[JRod]

Sorry for all of the posts but I wish I could see your post while composing mine.  I'm accessing the Minimserver directly from JRiver so I'm not copying anything anywhere.  That's the way JRiver sees MinimServer and I just have it connect. My tagging program is Yate. it's a reputable tagging program and always does what I want it to do with no issues.  All of the tags look correct in Yate.  Actually, if you look at the screen shot of the file names the disk and track number are embedded there as well. The tags also look correct from the Audio Station on the Synology NAS.  Like I said, JRiver is doing this to other multi-disk albums elsewhere in my collection. I don't know if JRiver folks can fix this or if they even want to. I don't know but I was looking for perhaps a simple adjustment somewhere in the JRiver configurations that would stop this behavior.  Why does executing "Update library from tags" temporarily fix the problem? if the tags were screwed up, it wouldn't. Unfortunately, restarting the program brings the problem right back.

[wer]

Ok I see some screenshots have been changed now. And not as many as there were before.  I see what you're talking about with the track numbers in one of the screenshots there now.  The tracks show as sequentially numbered, not starting over at #1 at disc 2.

You say you confirmed the tags, but I don't know where or how.  Since you haven't shown me any info from the tag dump window in MC (did you check that like I said before?) there's not much more I can say; they're probably right because the update works.  So something might be going wrong with the import process you're using. And that import process definitely prevents MC from fixing any problems in the files. The best way to access your music from another device isn't necessarily the best way to access them from MC. I wasn't telling you not to keep the files on your Synology, or not to use its web server for other apps. I was talking about the best way to give JRiver access to those files, so that you'll get better results.

The problem comes back when you restart because of the way you have imported your files.  You'll never be able to use MC to change your tags or fix other issues, they way you are importing. But I understand you don't want to hear that.

Also I don't have any control over the "JRiver remote app" (whatever you're referring to) since I'm a user just like you.  I'm just trying to help you. 

But I can see you're not interested in what I'm telling you about how you've inserted the tracks into the JRiver library, so I'm not going to argue with you. I'll say goodbye and bow out, and perhaps someone else will help you.  Good luck.

[JRod]

OK, I see I offended you and I'm sorry for that.  I do appreciate you taking the time to help me.  there may be a communication problem causing a bit of frustration on my part.  part of the problem is that you're talking over my head without you realizing that.  I'm sure you know a lot more about how JRiver works than I do.  You keep saying importing and I don't completely understand what is getting imported.  I have simply instructed JRiver to read my library.  if something is indeed getting imported anyway then I claim ignorance.  Also, I don't write any tags from JRiver either. the files are what they are and already properly tagged (from what I can see). I looked at the screen dump and it looks OK from my novice point of view.  it shows the correct disk and track numbers for the file being viewed.  its track 1/14 from disk 2.  I'm including 2 files of the tag dump as the tag dump window is small and I don't know how to make it bigger or if it can be. 

[JimH]

The wiki has information on Importing.

[JRod]

OK, investigating further I've realized this is probably a MinimServer thing where it just numbers the files sequentially regardless of disk number. I did happen to observe the same behavior with Foobar2000 as well. When I executed the "Update library from tags" the files looked right again (or the way I want them to look). Once JRiver is closed and reopened, the tracks are back to just being sequentially numbered disregarding the disk number again. is there any way to set JRiver to always arrange the files following the tag information automatically when opened? Or, can this be a possible feature request?

[JimH]

You may need to fix the tags in the files on the server.

[JRod]

Hi, Jim, the files on the server are indeed properly tagged.  First track on disk 2 is track# 1 and so forth.  Why Minimserver decided to handle the files the way it does is somewhat of a mystery to me and I'm searching the Minimserver forums to see if I can find the answer. Using Minimserver to serve up my music has otherwise been a great experience with stellar sound quality and few problems. Anyway, thanks for looking at this.