INTERACT FORUM

Please login or register.

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

Author Topic: Playback fails because library can’t find file, but file is correctly indexed  (Read 721 times)

OlivierPS

  • Recent member
  • *
  • Posts: 17

When I’m trying to play a file, I get this message: (Snapshot 01)

When I click the [No] button, I get this message: (Snapshot 02)

What is weird is why is MC trying to load the file from “Eugene Ormandy Conducts Mozart Wind Concertos”, when the filename in the library is (Filename) snapshot??? And the track name is not the correct one either.
When I do a “Locate on disk (external)”, MC shows me correctly the file. So, one can be certain that a) the file exists, b) MC is able to locate it in some way.

The name “ Eugene Ormandy Conducts Mozart Wind Concertos” was the “Album name” when I ripped the CD. I later edited the Name. One could think it’s part of the problem. But I have the very same problem with other rips I did today. In fact, everything works fine with the first CDs I ripped. But I have the problems with the latest ripped CDs. So, something must have gone wrong at some point.

Thanks in advance for your help.

Olivier :-{)

PS: MC 25.0.81 on a MacMini running MacOS 10.13.6
Logged

wer

  • Citizen of the Universe
  • *****
  • Posts: 2640

Try deleting the file from the JRiver library (not from disk) and then reimporting it, then try again to play it.
Logged

OlivierPS

  • Recent member
  • *
  • Posts: 17

I did it (before posting) and still get this weird behavior. I find it particularly puzzling that MC seems to keep a “memory” of the file. Maybe there’s a cache somewhere that could — and should — be deleted? Where and whow?

I’ve also been looking for a way to rebuild the library but didn’t find one. Does it exist?
Logged

wer

  • Citizen of the Universe
  • *****
  • Posts: 2640

I'm not an expert in this, but have encountered a similar situation.  Here goes...

MC does cache some information about files it's seen before.  This is keyed off of filename, so if you change the filename, MC will think it's a new file and not use the cached info.

There is a way to get rid of the cached data.  Create a smartlist-type playlist, and name it something like Deleted Files.  Remove any rule you see in the Edit Smartlist dialog.

Now click the Import/Export button and enter the following in the dialog box that appears:
~d=r
Click OK on the Smartlist Rules Importer dialog.
Click OK on the edit smartlist dislog.

Now you have this smartlist created.  Look at the contents.  It is showing you all the files that have been deleted from the MC database.  Like any other playlist, you can add other columns to see what MC has in various fields for that entry.

If you select a file in this smartlist and delete it, you should be prompted as to if you want to remove it from the database.  Say yes.  MC has now forgotten any cached info it had about that file.

In general, you can also test if the cache is the problem by renaming the file to a new filename MC has never seen before, as I said.  If the problem exists with an original filename, the problem is with the file not the cache.
Logged

OlivierPS

  • Recent member
  • *
  • Posts: 17

Sorry for the delay. I’ve conducted a series of tests and I think I’ve solved the problem. The problem comes from the “link” function. I’m listening — not exclusively but mainly — to classical music. In classical music, we don’t generally listen “track by track” but “work by work” and a work is generally comprised of a series of movements (i.e. tracks). Hence the use of the “Link start” function that allows one to choose works randomly, without disrupting the succession of the movements.

Now, when you’re about to rip a CD, you can edit all the metadata — which is absolutely necessary in classical music, because all the online data is pure rubbish — before starting the actual rip and that’s what I generally do. But don’t — absolutely don’t — use the “link start” function at this point. Otherwise happens what happened to me : when you’ll want to play your ripped tracks, JRiver will have kept the link pointing to the CD and, as it won’t find the CD, it will tell you it can’t find the track to be played ! So unless this behaviour is corrected in a future version, proceed like this for ripping your CDs :

  • insert the CD
  • edit the metadata at will, but don’t use the link start function
  • rip the CD
  • eject the CD
  • now you can group tracks (movements) in works with the link start function.
Have a nice day !

PS : maybe this could be considered as a bug and corrected in a future update ?
Logged

Davidhe19

  • Recent member
  • *
  • Posts: 8

Agreed.  I have encountered this problem with classical music importing.  I noticed normally it relates with the track with very long title.  I needed to hand-entered the title name, then identify the Album title to link the track with that specific album title.
Logged
Pages: [1]   Go Up