MM5 not showing new tracks after rip

[MattTown]

Hi,

Looking for some guidance here. I've recently started ripping a backlog of new CDs. In MM4 I was used to the newly-ripped tracks showing up in the general file listing straight away, as soon as the conversion finishes.

Now with MM5 I'm finding that the new tracks don't show in the file listing even with multiple resorts to check for date added, album/artist tags and pathname. To get the tracks showing in the filelist my simple fix is to restart mediamonkey, but there was one instance where some combination of new tabs and sorting prompted two of the tracks that had been ripped from a CD at that point in time to show up, without the others subsequently showing up.

I understand that setting MM5 to "continuously monitor" the folders where the CD will be ripped to (Tools | Options | Library | Add/Scan Settings | <MusicFilesFolder> | Schedule Continuous) would probably fix the problem. To date I have left "continuously monitor" off for my music folders because I have a slow system and don't want to further impact its response, and I thought that ripped CDs would be added to the library by default.

I don't recall that global monitoring setting being necessary in MM4. My recollection from MM4 was that a ripped CD would show in the main file list whether or not "continuously monitor" was set, but it was a while ago now and I could be wrong.
I'm happy with guidance to just set "continually monitor" if that is the intended solution, just thought I'd ask.

Cheers
Matt

[Lowlander]

Are you Ripping to a library location? For me Ripped files always show in the Library after they're ripped, no scanning required.

[MattTown]

Not sure what a "library location" is, but the tracks are going into the same general area as all of the other ripped CDs in the library, which are all under a root folder of "Mediamonkey Music Files" which is on a local drive, with Artist and Album subfolders. Same filename mask for all ripped files in my library.

Have been doing more ripping, with a related problem reported via the Bugs topic "CD Drive currently in use when ripping". What happens now is that all of the tracks ripped get shown on the file list *except for* the tracks that were interrupted by the drive in use error.

This "don't show last ripped tracks" seems to have been consistent over the last couple of days. Further experimentation showed the following to be consistently reproducible on my system:

• Config: Media tree left, filelisting centre, right showing now playing, art and lyrics. Filelist has one tab showing "Entire Library"

• Rip a CD with the filelisting showing. In this example the CD has 21 tracks, with three tracks being interrupted by the drive in use error.

• All ripped tracks show in the file list *except* those which were interrrupted, in this case tracks 1, 3 and 21.

• Resorting the filelist (eg via Artist, Path or Added) shows that the last-ripped tracks are missing from the filelisting.

• Looking at the destination folder in Windows shows that tracks missing from the filelist are present, so the ripping process did complete. Date Created shows that tracks 1, 3 and 21 were written after the other ripped tracks in the sequence 21, 1 and 3.

• Back in MM, use the + next to the original tab to open a new filelisting tab for All Tracks - last-ripped tracks show in the filelisting. The Added sort shows the missing tracks to have been added last, as per the windows create date.

So I have a workaround: Rip a CD, open a new All Tracks tab, close original All Tracks tab, proceed OR rip the CD with the filelisting changed to the CD drive itself and then change back to All Tracks when finished. To align the date added with the track sequence I remove the tracks from the library and then add them again via the File > Add/Rescan dialog. Clunky, but it works.

Overall, the rip process works and I can manage the wrinkles, but:

• If there is a device error from my drive (I have removed it from Device Manager and rebooted, no change), whatever device error is being generated is not elegantly handled by MM, and

• the fact that the missing files do turn up once a new filelisting tab is opened shows that the code that adds files to the original filelisting tab is not as robust as it could be.

I understand that this might just be an outlying case caused by my particular machine, but if you get other such reports it might help.

Cheers
Matt

[Lowlander]

Deal with the Rip error first as it may be the only problem you're really having (this may just be a side affect).

[MattTown]

Lowlander

Deal with the Rip error first as it may be the only problem you're really having (this may just be a side affect).

The CD Rip error has been fixed by returning the count of processors to use to 1, but I still have a missing track problem.

I'm doing another large batch of ripping so I'm seeing occasional behaviour as follows:

• Config: Media tree left, filelisting centre, right showing now playing, art and lyrics. Filelist has one tab showing "Entire Library"

• Rip a CD with the filelisting showing, sorted by Added to get new tracks at bottom.

• All ripped tracks show in the file list *except* the last track.

• Resorting the filelist (eg via Artist, Path or Added) shows that the last-ripped track is missing from the filelisting.

• Looking at the destination folder in Windows shows that the track missing from the filelist is present, so the ripping process doescomplete.

• Back in MM, use the + next to the original tab to open a new filelisting tab for All Tracks - last-ripped track shows in the filelisting.

This happens about half the time. I have two workarounds to get the last track visible in the main file listing so that it can share in metadata updates:
1. Rip a CD, open a new All Tracks tab, close original All Tracks tab, proceed in the new tab OR
2. Rip the CD with the filelisting changed to the CD drive itself and then change back to All Tracks when finished.

So having the last ripped track not show in the main file listing is a minor problem and is manageable, but in the absence of persistence and patience could be seen as a product defect by new users.

Cheers
Matt

[Lowlander]

Does this happen with Build 2829, does F5 fix it?

[IanRTaylorUK]

• All ripped tracks show in the file list *except* the last track.

So having the last ripped track not show in the main file listing is a minor problem and is manageable, but in the absence of persistence and patience could be seen as a product defect by new users.

Hi Matt,

Hi Matt, I have also seen the issue of the last track missing sometimes. Not just ripping (which I do infrequently) but when adding downloads.

Try - a). pressing F5 or b). File / Add Rescan... c). Exit MMW5 and re-open. Do the missing file(s) now appear?

The way I work-around / avoid this issue is to Rip or Download to a separate Drive / folder that is scanned continuously AND to batch my work. By this I mean adding ALL downloads / Rips to my F:\Downloads folder and then typically close MMW5 and re-open. I then do all the tag editing / volume analysis / BPM / Date To Year / Set Tempo / Clean Apostrophes / Case Checker and Update Tags. Once this is complete I Organise from F:\Downloads to MEDIA:\<Type>\<Album Artist>\<Album>\<Title>

In a separate Window, I then check the Organised files and add artwork, create a Playlist, check track sequence is complete.

The annoyance for me of the "missing track" is that 1). Album Volume analysis might be out, 2). Time to "correct" is about equal to the time to process (perhaps greater sometimes).

It is untypical for me to "add / process" a single album. I guess I average ~1000 tracks on a good day in a "single batch" from my F:\Downloads to MEDIA:\<Type>\<Album Artist>\<Album>\<Title>

[MattTown]

Hi Lowlander

Does this happen with Build 2829, does F5 fix it?

Yes it does occur with 2829 which I have been using since 24 December, two days before my last post (have just updated my signature).

Regarding F5 refresh, I wasn't aware of that and so didn't try it. I've run out of ripping for the moment but will give that a go when next I see the problem.

Ian,

Yes, closing and reopening MM will reliably show the missing last track. In some cases, simply opening another AllTracks tab will show it. I am confident that MM has taken in the last track and added to the database, there is just some sort of problemn that temporarily prevents it from being immediately shown in the main file list.

The annoyance for me of the "missing track" is that 1). Album Volume analysis might be out, 2). Time to "correct" is about equal to the time to process (perhaps greater sometimes).

I agree - having the last track not turn up does impair whole of album things like levelling and metadata correction, and just getting it to show is a relatively big time cost.

But it also goes to reliability - minor things like this detract from confidence in the software for casual users.

Cheers

Matt

[MattTown]

Hi Lowlander,

Does this happen with Build 2829, does F5 fix it?

Found another disc to rip. With the Entire Library list showing on the main panel while the rip occurred, sorted by Added with recent at bottom, the main list again failed to show the last ripped track after the rip completed and the disc was ejected.

The good news is that as per your suggestion, pressing F5 did immediately show the last track.

Cheers

Matt

[Peke]

The good news is that as per your suggestion, pressing F5 did immediately show the last track.

That is by design so that RIP and other library track add do not interrupt your current work.

[Rob_S]

This makes little sense to me - I think for most people, the rip task would in fact be their "current work"

Surely the impact of one last auto-refresh after completion would be minimal compared to the rip task itself??

This design feature should be fixed.

[Peke]

Hi,
Same refresh trigger would be also triggered when you scan files to library. So imagine 10k Track imports and number refreshes

This design feature should be fixed.

It was like that before, but much more users complained MM main Screen flashes too much

[Rob_S]

So it refreshes sufficiently to show all previous tracks, but not the last one???

I did say after completion, not after every track.....

[Peke]

Hi,

So it refreshes sufficiently to show all previous tracks, but not the last one???

Hmmmm, I am crazy then. I thought that you said you need F5 after all tracks finishes to get all (last included) or I am finally seeing what exactly the problem is eg. What I tried is Start RIP -> Wait till it is done -> Press F5 (List view entire library sorted Descending ADDED) -> All ripped tracks are there.

I did say after completion, not after every track.....

You are right, but I would prefer Toast MSG with Refresh button, so that user can choose to refresh or not as Refresh can influence track selection in main view.

[IanRTaylorUK]

Ian,

Yes, closing and reopening MM will reliably show the missing last track. In some cases, simply opening another All Tracks tab will show it. I am confident that MM has taken in the last track and added to the database, there is just some sort of problem that temporarily prevents it from being immediately shown in the main file list.

The annoyance for me of the "missing track" is that 1). Album Volume analysis might be out, 2). Time to "correct" is about equal to the time to process (perhaps greater sometimes).

I agree - having the last track not turn up does impair whole of album things like levelling and metadata correction, and just getting it to show is a relatively big time cost.

But it also goes to reliability - minor things like this detract from confidence in the software for casual users.

Cheers

Matt

Hi Matt, I agree.

A casual user "cautiously" adding music files by album, might end up with 1 track for each album incorrectly tagged / wrong album volume etc. Likely to lower their Confidence and increase their confusion if not ALL of an album's tracks / tags edited in sync!