Print

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

[richard-ec2]

I'm ripping a lot of CDs at the moment from classical boxed sets and a problem I keep coming up against is that MC22 often doesn't import the final track of the ripped CD. I am using dBpoweramp for ripping - with lossless FLAC - but I know it's not a ripping error because you can see the ripped file sitting there in the ripped folder, just waiting to be imported.

Often, MC will import the missing track if you wait long enough. (Which confirms that it's not a ripping error.) But sometimes the missing track is still missing long afterwards and I'm afraid to just leave it in case it never appears. I've found there are two ways of nudging MC into importing the track: if you re-rip it with dBpoweramp, this always fixes it - MC imports the track as soon as the re-rip begins and you don't even have to wait for the re-rip to finish. Or you can open the ripped folder with Mp3tag and re-save the existing tag data, and that also seems to nudge MC into importing it.

Not the biggest problem I realise but it's slightly frustrating when you're ripping a lot of CDs - it does slow the process down, having to check every import and often having to re-rip the last track .

While I'm here, can anyone explain why Mp3tag can't overwrite the Album Artist tag field in MC? Let's say I rip a CD with dBpoweramp (lossless FLAC) and import the files into MC, then realise I've entered some incorrect tagging info including the Album Artist. So, using Mp3tag, I open up the folder and correct the tags. Most of the changes take effect in MC but for some reason Album Artist never does - it remains the same in MC even though M3tag has successfully changed on the audio file. The only way to fix this is to change the Album Artist tag manually in MC.

[JimH]

Did you try updating?

[blgentry]

I'm guessing you're using auto import.  Do you have auto import running in the background to pick up new files all the time?  Or do you have to press the auto import button to start it?  I'd suggest trying the auto import button.  That should make MC pick it up.  You can trigger auto import with Tools > Import > Run Auto Import Now .

Or you can add it to the tool bar if you want to use it often.

Brian.

[richard-ec2]

Did you try updating?

If you mean updating MC, yes, MC updates itself automatically at frequent intervals.

I'm guessing you're using auto import.  Do you have auto import running in the background to pick up new files all the time?  Or do you have to press the auto import button to start it?  I'd suggest trying the auto import button.  That should make MC pick it up.  You can trigger auto import with Tools > Import > Run Auto Import Now .

Or you can add it to the tool bar if you want to use it often.

Brian.

I have auto import running in the background to pick up new files all the time. I will try forcing an import with
Tools > Import > Run Auto Import Now next time it happens but I'm pretty sure I tried that on a previous occasion and it didn't have any effect.

[richard-ec2]

It just happened again - didn't import the final track out of 11 tracks ripped. So this time I manually ran
Tools > Import > Run Auto Import Now and it worked! It immediately imported the missing track. So that's another option for importing the missing track.

However, it worries me that I have to resort to these methods. In the past, the missing track hasn't imported even after closing down and restarting MC and I'm afraid it never will import unless I use one of these manual methods. It's a little bit tiresome having to check every rip to make sure all the tracks are there and often having to import the last track manually. I wonder why it's happening?

[blgentry]

Auto import is probably triggered by the file system event that is triggered when the *first* file is created.  Because you're ripping to a NAS, the file system events might not be quite as reliable as a native OS based file system.  Just speculating.

I like auto import.  But I've now settled on using the Auto Import button instead.  It's just one extra click after I rip a disc or two or three, so it's no big deal.

Did you know you can add buttons to the top bar of MC?  Right click just above the play button area and you should get "customize toolbar".  This will allow you to add a "run auto import" button.  ...and others if you want.

Good luck.

Brian.

[JimH]

I believe that on a NAS, it may be done with a timer, so that eventually the missing track would be picked up.

[richard-ec2]

I'm not running any NAS - I don't know where that came from! My set up is as simple as could be  - I'm sitting at a powerful Windows 10 desktop PC with everything on this one PC, ripping straight from the optical drive to the hard drive. So it's not a NAS that's causing the problem. Thanks for the suggestions, though.

[blgentry]

I apologize for introducing a false claim into this discussion.  That's my mistake.  NO NAS! 

Sorry about that.

Brian.

[DJLegba]

I rip to a local drive and then copy across the network to an external USB drive on the MC server. For a while I was using a very slow ethernet over power adapter, and MC would frequently miss the last track when importing. A while ago I ditched the power adapter and ran a gigabit ethernet cable to the MC server. Copying rips takes seconds now instead of minutes, and MC always imports the last track.

[RoderickGI]

I see this sometimes importing TV episodes. They do always import eventually, but sometimes it takes a while, and sometimes they don't pick up Cover Art or the correct metadata.

What I found was that some of my TV recordings were corrupted, and MC was getting stuck on Audio Analysis, so the background Auto Import task was never completing. I used a manual run of Auto Import to identify the problem, via the Action Window which showed the process was stuck, and then via logs to identify which file set was corrupted.

So, how does a TV problem have anything to do with not picking up the last track, when the file is obviously there?

As you are using dBpoweramp to rip the CDs, I suspect that the file for the last track isn't being released either by dBpoweramp or by Windows after dBpoweramp finishes with it. The file is still in use, so MC can't write tags to it, which I have no doubt it tries to do as part of the import process, if only to write the file name and path to the file.

So, you have a couple of choices to fix this;
1. Use MC to rip your CDs. It works, although some people have had problems.
2. Either close dBpoweramp after you have ripped a/some CDs, or work out what you have to do in dBpoweramp to force it to release the last file it ripped. Maybe close the ripping dialogue and go back to the menu, or similar? But Windows doesn't release a file sometimes, even when the application using it has closed. So sometimes you just have to wait a bit. Also there may be other applications that touch the file once it is created, such as a virus scanner. A virus scanner shouldn't lock the file though, and hopefully neither should other applications. Is Windows Indexing service turned on for your music location?
3. Manually run Auto Import after ripping a group of CDs, and check that all tracks imported correctly.

Basically, this issue looks like a MC problem, but I suspect that it is actually a Windows/environment problem. Maybe there is something in the logs which would show that the last track wasn't imported, and possibly why, such as file in use. Maybe someone can help in suggesting what to look for in the logs, although just searching for the file name in the log should show something.

[richard-ec2]

That's very interesting, RoderickGI, and I think it's almost certainly the answer - something is hanging on to the last file and preventing MC's auto import from importing it. I've noticed when ripping a batch of CDs that sometimes the artwork doesn't immediately appear for a ripped album and when I try to add it manually, MC gives me an error message saying it can't do that because the file is in use or something like that - even though the rip is complete. So I think dBpoweramp is for some reason not releasing the last file in time for JRiver to do its auto import - or else, as you say, Windows considers the last file to be in still in use by dBpoweramp and therefore won't release it to another app.

Now you've given me an understanding of what's happening, I can do more tests. It will be interesting to find out, for example, if closing down dBpoweramp is enough to release the last track; or if ejecting the disk is enough to achieve the same; or if ripping a new disc or even just ripping another track off the same disc is enough to do it.

To me, the really big question and perhaps the only important one is whether a track that doesn't auto import (at least initially) will, eventually, appear. Does MC keep on trying to import a track for ever, until it succeeds? I need to do some tests on this to discover whether MC will always, eventually, import the missing track, even if it's not until the PC has been rebooted. So I'm going to start making a note of which tracks haven't imported and instead of forcing an import, I will simply wait and see, days if necessary, to see if they eventually appear.

Many thanks indeed for solving this riddle. Now I understand what's happening, it's a lot easier to see a way around it. No more unfinished symphonies! Maybe this explains Schubert's 8th - he actually wrote the whole thing but the last track was open in another app and he died before he could reboot his PC.

[PAR57]

" So I think dBpoweramp is for some reason not releasing the last file "

I hope that this isn't a dumb suggestion but have you checked the " Verify Written  Audio" box in dbPower amp? That generates a log of all the ripped tracks and their status.  It should show if all processes are complete.

[richard-ec2]

Not dumb in any way. Yes, I have ticked that box in dBpoweramp and I get a full "success" log after every rip. I think it's quite possible that it's Windows that's not releasing the final track as long as the dBpoweramp app remains open.

Thinking about it, however, two things remain unexplained:

1. Why is this behaviour inconsistent? More than half the time, all tracks are successfully imported into MC without any problem.

2. Why is Mp3tag able to read the tags when MC cannot? If I have a folder of ripped tracks, the last track of which hasn't imported into MC, I can open the same folder in Mp3tag and this shows that all the tags are present. The odd thing is, if I then do a "save" in Mp3tag without altering anything, MC then imports the last track! So it would seem that Mp3tag is able to grab the file away from whatever's holding it, but MC isn't.

[JimH]

You could save yourself some trouble by ripping with MC.

[PAR57]

Not dumb in any way. Yes, I have ticked that box in dBpoweramp and I get a full "success" log after every rip. I think it's quite possible that it's Windows that's not releasing the final track as long as the dBpoweramp app remains open.

Thinking about it, however, two things remain unexplained:

1. Why is this behaviour inconsistent? More than half the time, all tracks are successfully imported into MC without any problem.

2. Why is Mp3tag able to read the tags when MC cannot? If I have a folder of ripped tracks, the last track of which hasn't imported into MC, I can open the same folder in Mp3tag and this shows that all the tags are present. The odd thing is, if I then do a "save" in Mp3tag without altering anything, MC then imports the last track! So it would seem that Mp3tag is able to grab the file away from whatever's holding it, but MC isn't.

Thanks for saying that my last comment wasn't dumb but I shall continue in dumb mode.  One thing that I am not clear on. Your setup is a direct rip to hard drive. Before seeing if MC has imported the last track, is it actually there on the hard drive to import? I am thinking along the lines of an album file being too large in some cases if you are using e.g. a FAT file format. That would help explain  the inconsistency. However I am probably on the wrong lines as usually this would result in the entire file being junked. Anyway it may be worth looking at to see if you are attributing the fault to the right software.

[richard-ec2]

One thing that I am not clear on. Your setup is a direct rip to hard drive. Before seeing if MC has imported the last track, is it actually there on the hard drive to import?

Thanks but the file definitely is just sitting there waiting to be imported, and as I've mentioned before, you can see that it's tagged correctly because you can use Mp3tag to read the tags. Yet MC won't import it.

I honestly think we already have our answer as provided by RoderickGI: for some reason MC can't or won't import the last file because it appears to be in use by another app (presumably dBpoweramp). What's still a bit puzzling is why this often happens but more often doesn't. There must be a particular set of circumstances that triggers this behaviour and maybe if I rip enough CDs, I'll one day discover what it is.

[Fitzcaraldo215]

I have this "file in use by another app" conflict all the time, even just in Windows 7 Explorer while copying, etc. files to/from folders.  Sometimes, I just give up and reboot.  Or, as I have discovered, log out and log in to my user account, which is slightly quicker.

Note that this happens completely independently of JRiver, but in Windows itself with no other apps involved!  Grrr!

Not sure if this solves your problem, though. 

I should mention that I have ripped thousands of SACDs and imported them to JR, and I never had your problem.

[richard-ec2]

Do you mean the "The Action Can't be Completed Because the Folder or a File in it is Open in Another Program" message? I used to get that all the time but found a fix - you have to turn off thumbnail caching. There's a useful guide here but you only need to use Method 2:

http://troubleshooter.xyz/wiki/fix-folder-in-use-the-action-cant-be-completed-error/

Since I've already done this I don't think it's the answer to my problem but I hope it helps someone else!

[RoderickGI]

1. Why is this behaviour inconsistent? More than half the time, all tracks are successfully imported into MC without any problem.

I suspect this is just a timing issue. Sometimes the file has been released and MC can import it, sometimes it has not, so MC can't. MC would be trying to import the file immediately after it is created on disk, so we could be talking microseconds before it is released by dBpoweramp. Maybe dBpoweramp releases the file, but then the verify process immediately locks it again. Although if that was the case I would expect issues with all tracks. Maybe the length of the track contributes. Maybe it is just Windows being too busy on other things to complete the process. As mentioned above, I have also had Windows Explorer hold on to a file just because it had done a copy.

2. Why is Mp3tag able to read the tags when MC cannot? If I have a folder of ripped tracks, the last track of which hasn't imported into MC, I can open the same folder in Mp3tag and this shows that all the tags are present. The odd thing is, if I then do a "save" in Mp3tag without altering anything, MC then imports the last track! So it would seem that Mp3tag is able to grab the file away from whatever's holding it, but MC isn't.

Again, a timing issue possibly. By the time you have tried to open the file in Mp3tag, it has been release. MC has already tried and failed to import it, so it has left the file for a later import process.

When you do a save with Mp3tag, that generates a System File Event, which is one thing that triggers MC to import, or update, a file. So it makes perfect sense that MC immediately imports the file after a save.

MC can see the file no problem. Mp3tag isn't doing anything special. Try this; instead of opening the file with Mp3tag, try playing it with MC, without having imported it, via Windows Explorer. I would be surprised if that didn't work, because, timing issue.

I believe MC will always find the last track file and import it eventually, because MC Auto Import will look for changes inside directories at time intervals, in addition to being triggered by System File Events.


As Jim says though, unless there is an important reason to use dBpoweramp to rip CDs, you could use MC to do the ripping and wouldn't have the problem.

[JimH]

As Jim says though, unless there is an important reason to use dBpoweramp to rip CDs, you could use MC to do the ripping and wouldn't have the problem.

Doing that would also tell you whether the problem has anything to do with dBpoweramp.

[richard-ec2]

Good answers, RoderickGI - many thanks. That's an interesting theory about the length of the last track determining whether or not the problem occurs - I'll watch for this in future rips. It's classical music I'm ripping at the moment and the last track can often be very long if, for example, it's the last movement of a symphony. So I think that might very well be the explanation.

I believe MC will always find the last track file and import it eventually, because MC Auto Import will look for changes inside directories at time intervals, in addition to being triggered by System File Events.

That gives me comfort. The worry would be if MC Auto Import gave up after trying and failing to import the track. But if MC keeps on trying until it eventually succeeds, then it's more a curiosity than a problem.

I'm sure this wouldn't happen if I used MC for ripping but at the same time I doubt whether it's a problem with dBoweramp since this is a paid-for app with its own support forum and I don't see any indication that it has ever been raised as an issue there. I'm not blaming MC either - it just seems to be a quirk in the way MC, Windows and dBpoweramp work together, and even then, maybe only with long tracks.

[Antognini]

To investigate what might be holding a file, you can use the Handle utility available through SysInternals (part of Microsoft). I've used that a few times in the past.

[DJLegba]

Just as an experiment, try ripping to a folder that MC isn't watching. Once the rip is complete, copy or move it into the watched folder. I suspect MC will always see the last track in that case.

[richard-ec2]

To investigate what might be holding a file, you can use the Handle utility available through SysInternals (part of Microsoft). I've used that a few times in the past.

That would be interesting - I've downloaded utility but it's not very user-friendly and I'm not sure I can figure out how to use it.

Just as an experiment, try ripping to a folder that MC isn't watching. Once the rip is complete, copy or move it into the watched folder. I suspect MC will always see the last track in that case.

Yes indeed, I'm very sure it would - it's only during "live" ripping that the problem occurs.

[Antognini]

Umm ... Yes, the utility does assume some familiarity with Windows. But I just tried these steps, using Handle64.exe ('cause my OS is x64, although probably handle.exe would work, too):

1) Let's assume that Handle64.exe is in c:\SysInternals\Suite. Let's further assume that there is c:\Temp. So, in a command window (eg, hold down the Windows key, then the R key, then enter 'cmd', then enter):

  c:\SysInternals\Suite\Handle64.exe > c:\Temp\x.txt.

2) Use notepad.exe (part of Windows) to browse c:\Temp\x.txt in the command window.

3) In notepad, look for 'JRiver'. In my system (Windows 10 Pro x64, JRiver Media Center 22.0.108), I got hits for 'Media Center 22.exe' (that's one process for JRiver) and for JRWeb.exe (another process). Look for lines under each process that are identified with 'File': These will be file handles, and if Media Center is keeping a file open after ripping a CD, you might find the file handle for one, presumably the last, file.

[richard-ec2]

That's very kind - in fact it's dBpoweramp that's suspected of holding on to the file rather than MC but I think I get the idea and it's worth a shot next time this happens. Many thanks for the suggestion.

[DJLegba]

That's very kind - in fact it's dBpoweramp that's suspected of holding on to the file rather than MC but I think I get the idea and it's worth a shot next time this happens. Many thanks for the suggestion.

It's not a dbPoweramp issue though as the same thing happens if the network copy is slow.

[richard-ec2]

It's not a dbPoweramp issue though as the same thing happens if the network copy is slow.

True. It seems to happen whenever MC tries to import the last file while it's still being written or handled by another process, whether it's dBpoweramp or the network. I'm not sure it's even a problem as long as the file gets imported eventually. Maybe the answer is to build in a slight delay between MC's detecting a new file and the start of the import process? Just a second or two. But I'm out of my depth technologically.