Print

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

[JimH]

This is the latest version of MC 12.0.  Any MC12.0 license will work with it.  Please post bugs here.  Please start a new thread for anything requiring discussion.  Non-bug posts will be deleted or moved.

This latest build (usually safe) of MC12.0 is here:
ftp://ftp.jriver.com/pub/downloads/MC12/MediaCenter120493.exe

12.0.493 (5/6/2008)

1. Fixed: TWAIN scanning was not working properly.
2. Optimized: Panes with many items fill and refresh much faster.
3. Fixed: Edit Image changes were not being applied to pix01 galleries.
4. Fixed: (Hopefully fixed) When switching digital TV channel immediately after starting another channel, MC would sometimes behave strangely.
5. Changed: On the right click menu.  Play and Add to Playing Now will not honor position.  Creating a stack will honor the position.
6. NEW: Added option to ignore (and not ignore) leading articles (a, an & the) in artist names when transferred to an iPod.
7. Fixed: Tab controls could obscure internal controls.
8. Fixed: Thumbnails could be erroneously reset during thumbnail database compacting.
9. Fixed: Using the /SilentImport command when the program was not running could cause a crash.
10. Changed: When drawing multiline text, if all the lines can't be rendered, a ... will be added to the end of the last line.
11. Fixed: Some Action Window text would not truncate properly when the window was too small to display it all.

12.0.492 (5/2/2008)

1. Optimized: Panes fill and refresh faster.

12.0.491 (5/2/2008)

1. NEW: New internal database format used to store filenames, reducing total memory footprint of the database by over 50% in many cases.
2. Fixed: When filling cover art from a URL, the image could be unnecessarily reencoded as a new JPEG. (non-JPEG images are intentionally converted to JPEG)
3. Optimized: Removing files from a large Playing Now or large playlist is much faster.
4. Fixed: Printer configuration button in Print Wizard would not show the printer properties.
5. Optimized: Improved performance of database saving.
6. Fixed: Recommendation engine could stall MC's shutdown process.
7. Changed: DVD player now can handle aspect ratio correctly even if the video is resized by a post-processing filter (e.g. FFDShow).
8. Changed: Changed how analog TV channels are played with Hauppauge WinTV HVR 1600 device. Experimental.
9. Fixed: Rip filenames with dots in them were not working.
10. Fixed: Library Server could crash on starting/stopping, after an unsuccessful startup.
11. Fixed: Crash while clicking around the podcasts fixed.
12. Changed: Some code changes in DVD playback, to head off potential crashes due to bad DirectShow system or filters. Also added more logging.
13. Changed: Improved how OR's and AND'd rules are handled in the Smartlist Editor.

12.0.490 (4/30/2008)
   
1. Fixed: UNC path browsing in Disk Location view schemes did not work properly in the tree.
2. Fixed: Pasting strings with unsupported characters (tabs, non-printables, etc.) into the search box would do nothing.
3. Fixed: Cleaned up some wording with Rename, Move, & Copy Files tool.
4. Fixed: Possible crash while analyzing audio using the popup dialog.
5. NEW: Audio Analyzer dialog is sizable, remembers last position, and doesn't disable the list during processing.
6. NEW: Audio Analyzer dialog can run multiple analyze processes at once. (defaults to 2)
7. Fixed: Holding shift while drawing a right-click lasso in a list wouldn't do additive selection.
8. Changed: Dropping files to transfer on a handheld while it's gathering the files already on the device will show a wait message (with cancel) instead of doing nothing.
9. Optimized: Generic storage card devices or user-created virtual devices gather files the first time the handheld is used, instead of at startup. (so missing network drives, mapping a huge drive, etc. won't cause performance issues)
10. Optimized: Improved performance of list rendering when viewing handheld transfer progress.
11. Fixed: When adding a file that's already in Playing Now to the end of Playing Now, playback would begin with the first instance of the file.
12. Changed: The default restored size of the main application is 80% of the screen instead of a hard-coded value in the skin. (program starts maximized by default)
13. Changed: Revised how list style (details, thumbnails, etc.) is saved so that if it is changed to the default mode for a view, the list style will automatically adapt to the media types in the list.
14. Changed: Track Info visualizations create the generated HTML file in the temporary folder instead of the Program Files folder (to avoid permissions issues).

[Efjay]

Does this mean that:
"READ BEFORE YOU CLICK -- Back up your library.  Changes were made to the database that could result in data loss."

no longer applies (other than as good sense)?

[craft]

Very heavy memory usage - 114 324 K and CPU fluctuates between 50 and 80
Been playing MP3's for ~30min in shuffle mode

[JimH]

Very heavy memory usage - 114 324 K and CPU fluctuates between 50 and 80
Been playing MP3's for ~30min in shuffle mode

Could be a virus checker.  Please start a new thread.

[Lasse_Lus]

9. Fixed: Using the /SilentImport command when the program was not running could cause a crash.

thanks 

[MusicHawk]

Follow-up to my .492 report on MC crashing:

I was doing some more of the same, ripping CDs to MP3, doing a brief play of each track, then updating its tag. This time, MC didn't crash, but a few times, I got an error and lost the tag changes -- and I lost the entire track from the database.

1. Selected a track, started it playing, then updated its tag.
2. Clicked on the next track to start it playing (the previous track was still playing).
3. While editing tags of the second track, MC popped up an error box saying it could not update the tags of the first track. MC opinioned that it might be busy or misssing or something. Odd because I'd already stopped playing it, and the file was still there (I wasn't changing file name or location).
4. Continued to move down the list of tracks, repeating the process for each. About 10% of the time I got the error box, but mostly it worked fine. I don't know what in my behavior differed, but likely some tiny variation in my timing of clicks, and/or time needed by MC/PC to respond.

Oh well, I figured, I just have to go back to the few "can't write" tracks and do another small tag edit and likely the tag changes will write to the file successfully. So I continued through all 50 tracks.

But when I went back, the tracks were MISSING from the database! (I was in the "newly ripped" view so seeing nothing but the 50 tracks I ripped). I checked the drive and the tracks were still there, so I dragged them back into the view, edited the tags (again) and finished the project.

But what caused the "can't write" errors, and scarier, why did the database lose the tag edits, and most scary, why did the database discard the tracks' records? If I hadn't noticed, the tracks might have been "lost" forever.

All I can think to do is "slow down" the steps, but I think I'm working at a normal pace (other than, I'm a fast typist). When editing tags do I need to give MC a pause between tracks?

[JONCAT]

Erase orphans enabled and after trying to load a library via WAN unsuccessfully I lost most thumbs (2gb to 26mb). All the files in the local library are network files with local copy of thumbnail and library folder. Should this have happened?

DC

[JimH]

They will probably rebuild.

[Matt]

Follow-up to my .492 report on MC crashing:

I was doing some more of the same, ripping CDs to MP3, doing a brief play of each track, then updating its tag. This time, MC didn't crash, but a few times, I got an error and lost the tag changes -- and I lost the entire track from the database.

1. Selected a track, started it playing, then updated its tag.
2. Clicked on the next track to start it playing (the previous track was still playing).
3. While editing tags of the second track, MC popped up an error box saying it could not update the tags of the first track. MC opinioned that it might be busy or misssing or something. Odd because I'd already stopped playing it, and the file was still there (I wasn't changing file name or location).
4. Continued to move down the list of tracks, repeating the process for each. About 10% of the time I got the error box, but mostly it worked fine. I don't know what in my behavior differed, but likely some tiny variation in my timing of clicks, and/or time needed by MC/PC to respond.

I don't understand this, because the program won't try to save a tag until it's able to open the file for write access.  This should be after any playback related I/O is finished.

But when I went back, the tracks were MISSING from the database! (I was in the "newly ripped" view so seeing nothing but the 50 tracks I ripped). I checked the drive and the tracks were still there, so I dragged them back into the view, edited the tags (again) and finished the project.

Is it possible the ripping process was still working with them?  Were they missing from that playlist or from the library in general?

Thanks.

[AoXoMoXoA]

Adding images (cover art files) to Playing Now with the audio files causes MC to stop playback when it reaches an image file, until manually advanced.

question - When tagging an album of music with it's cover art files, if both file types are selected, items in the right-click menu which are not applicable to one type of file do not appear. This requires you to un-selectize the image files before you can apply cover art or analyze the audio files.
Could the operations not be visible and usable, but of course only alter the files of the proper filetypes?

[MusicHawk]

Hi Matt,

Nope, the ripping was long-finished. Other than possibly still-playing (though it seemed finished because I'd started playing the next track) I don't know why there would be file-open contention. Is it possible that MC was trying two operations on the same file at the same time?

When the tracks disappeared from the view after the "can't save tags" message, I didn't check the library overall. I just stayed in the Recently Ripped view (where they disappeared), and looked in the temp rip folder on the hard drive (where they still existed).

Since it "feels" like trying to open/write to a file that can't be opened/locked, I wonder if the "can't write" error actually happened several seconds earlier, when the file was still playing, and there was a small delay before the error message was displayed? Or, is it possible that the playback process doesn't always release the file promptly? I'm using a dual-core PC, if that matters. Could hard drive buffering be a factor?