Print

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

[zombie-wmd]

greetings -

Bug #1 - although startup options have the option of starting the server only, in practice specifying this option results in starting both the server and the UI (user interface).

Bug #2 -  MC prevents OS X from either manually or automatically shutting down.  after experimenting, i have discovered that it’s the server that is preventing shutdown.  shutdown will occur if only the UI is running.  i’m not the only one that finds this to be a problem.  i just discovered the wiki on MC command line commands and the associated MCC_SHUTDOWN.  Perfect, except that it’s only for Windows.  Is there any love for OS X?

Bug #3 - Not sure if this is a bug or if it’s an artifact of having auto update turned on, either way, it’s infuriating.  When my NAS shuts down for the night and MC is still running on OS X (see bug #2) then MC loses connection with my music files.  It seems like when this happens then MC tries to ‘reaquire’ some cover art. Which cover art varies from occurrence to occurrence and only affects a subset on my albums, but it’s almost always wrong; I assume it’s going out to the internet to get the covers.  this results in 2 incredibly intrusive things happening.  1) the art that was not originally correctly found when i imported the file and which i painstaking found and imported (usually, but not always, via copying/pasting to/from the clipboard using an image from Amazon (all praise to Amazon for resolving even the most obscure albums)) is now replaced with incorrect cover art.  2) because i store the cover art in the tag fields, even some of the cover art that was placed in the fields when the CD was originally ripped is replaced.  this is an order of magnitude more infuriating because the originial art is now lost, forever.  again, all praise to Amazon.  don’t know why only some small subset of albums is affected this way.  i can’t experiment to discover if this bug would happen is only the server were running because of bug #1.  also, it seems, if i have the OS X machine be a client to a server running on a Windows machine the same cover art kerfuffle happens.

Bug #4 - this is also a bug under Windows.  out of 200+ albums, <10 albums do not correctly import the 1st track, with the first track being called ‘track 1’.  after experimentation, i can say it has nothing to do with file name length or obscure characters in file name and the file is named correctly on disk.  if i change the file name to start with another track number, i.e. the next available track number on album, then the track is recognized.  dare i mention that which shall not be named and relate that Kodi has no problem in this regard.  it’s no big deal as i can easily fill in the information manually.  i mention it here because it seems bug #3 has again caused the loss of some 1st track information, although it may also be that i have discovered more albums that were never right.

these problems don’t change my opinion of MC, still top shelf.

thanks for any response.

[blgentry]

out of 200+ albums, <10 albums do not correctly import the 1st track, with the first track being called ‘track 1’.  after experimentation, i can say it has nothing to do with file name length or obscure characters in file name and the file is named correctly on disk.  if i change the file name to start with another track number, i.e. the next available track number on album, then the track is recognized.

I don't understand the problem description. Please provide an example with metadata.  Screen shots would be awesome, but cut and paste would work too.  I just need to try to understand the details of what you are describing.

For the record, I haven't had this happen with any albums in my modest (~300 album) collection.

Brian.

[zombie-wmd]

I don't understand the problem description

Brian -

i guess you're referring to bug #4.  i already fixed the misnamed tracks, but i can re-describe the problem.  for the cds that have this problem, when they were imported the name of the first track was not diagnosed correctly.  instead of the true name showing in the list of tracks (in the bottom window) when an album is selected, the 1st track is named simply 'track 1'.  all other tracks are correctly named.  the file name in the file name column (in the bottom window) of the incorrectly named track is correct, e.g. 'n:\Tom Waits\Bone Machine\01 Earth Died Screaming Bone Machine.wav'. to fix i just edit the name tag, but really those are easy enough to correct.  i only put it in this post because it looked like bug #3 regressed a couple of fixed tracks, but it maybe that my frenzied investigation of the cover art problem just uncovered some incorrect track names that i previously missed.

i'm more concerned with bugs #1-3?  i know we've gone round and round on the shut down bug, but it is a bug and its still a problem that causes further problems.  to suggest not shutting down the NAS is not going to work for me, or others.

regards

[blgentry]

I have nothing more to say on the matter as I'm not a developer and, as you've said, we've discussed these before.  Perhaps someone else can offer a fresh perspective.

Good luck.

Brian.

[JimH]

What version of MC are you running?  Did you try the one from a thread near the top of this board?

[mwillems]

Bug #3 - Not sure if this is a bug or if it’s an artifact of having auto update turned on, either way, it’s infuriating.  When my NAS shuts down for the night and MC is still running on OS X (see bug #2) then MC loses connection with my music files.  It seems like when this happens then MC tries to ‘reaquire’ some cover art. Which cover art varies from occurrence to occurrence and only affects a subset on my albums, but it’s almost always wrong; I assume it’s going out to the internet to get the covers.  this results in 2 incredibly intrusive things happening.  1) the art that was not originally correctly found when i imported the file and which i painstaking found and imported (usually, but not always, via copying/pasting to/from the clipboard using an image from Amazon (all praise to Amazon for resolving even the most obscure albums)) is now replaced with incorrect cover art.  2) because i store the cover art in the tag fields, even some of the cover art that was placed in the fields when the CD was originally ripped is replaced.  this is an order of magnitude more infuriating because the originial art is now lost, forever.  again, all praise to Amazon.  don’t know why only some small subset of albums is affected this way.  i can’t experiment to discover if this bug would happen is only the server were running because of bug #1.  also, it seems, if i have the OS X machine be a client to a server running on a Windows machine the same cover art kerfuffle happens.

I think I can tell you why the issue is happening and if I'm right, it's easy to resolve through JRiver settings.  It's a cross-platform issue (not just Mac).  I'll bet that you:

1) Have auto-import enabled
2) Have auto-import configured to find cover art, and
3) Have auto-import's fix broken links setting set to "Yes" or "Yes (protect files on missing drives)".

I've seen very similar behavior to what you're describing and here's how it works:  you turn off your NAS, and autoimport (sooner or later) notices there's been a "change" to the source.  It attempts to scan the (now missing) NAS drive, finds no files, and proceeds to remove some (or all) of the broken links depending on how much time it has to work.  When the NAS is turned back on, autoimport detects new files in the watched location (because the old ones have been removed) and reimports them looking for new cover art online(replacing the old cover art).  

The solution is to set "fix broken links" to "No."  This will ensure that the files are never automatically removed, preventing them from being automatically reimported. The "protect missing drives" setting doesn't work reliably in all cases and can lead to the kind of results you're seeing, so set fix broken links to "No".  If you need to clean up broken links automatically at some future point, you can always turn it on temporarily.

[zombie-wmd]

I think I can tell you why the issue is happening and if I'm right, it's easy to resolve through JRiver settings. 

great, thanks for the reply.  i'm onboard 100% with your answer.  my suspicion was that a combination of settings was the culprit, i just didn't know which ones.  i will try your suggestions.

one last thing along these lines.  i am ambivalent about where to store cover art.  why would i would want to store cover art in a tag, in addition to 'in the same folder as the file'?  is it a portability issue or something to do with jremote.  why would i want to store cover art in a tag?  i back up, via a file sync program, my music files to Amazon's S3 and every time cover art changes and it's in a tag, then a whole lot of new uploading to S3 goes on.  i'd prefer to avoid that.  is just storing it in the folder sufficient?  why are there 2 options?  if i change my options to just store in the folder will art currently in tags be deleted, thereby forcing an entire resync with S3?

thanks

[mwillems]

great, thanks for the reply.  i'm onboard 100% with your answer.  my suspicion was that a combination of settings was the culprit, i just didn't know which ones.  i will try your suggestions.

one last thing along these lines.  i am ambivalent about where to store cover art.  why would i would want to store cover art in a tag, in addition to 'in the same folder as the file'?  is it a portability issue or something to do with jremote.  why would i want to store cover art in a tag?  i back up, via a file sync program, my music files to Amazon's S3 and every time cover art changes and it's in a tag, then a whole lot of new uploading to S3 goes on.  i'd prefer to avoid that.  is just storing it in the folder sufficient?  why are there 2 options?  if i change my options to just store in the folder will art currently in tags be deleted, thereby forcing an entire resync with S3?

thanks

It's partly about portability, and partly about convenience.  If you store it in the file, you know it will always follow the file wherever it goes even if the folder.jpg gets separated somehow (which can happen a lot of different ways).  There are also different media players floating around and some don't look for cover art in the directory, only in the file (there are several android players like that). 

Personally I do both as the "data cost" is low and redundancy is handy. 

[zombie-wmd]

Personally I do both as the "data cost" is low and redundancy is handy. 

hopefully, your prior option change suggestions will stop this infuriating cover changing and i won't have to worry about incurring further S3 uploads, and can therefore keep cover art in both places.

thanks for your help, have a good life.

[zombie-wmd]

What version of MC are you running?  Did you try the one from a thread near the top of this board?

greetings -

i'm running 21.0.8.  according to the help menu, submenu - update channels, automatic updates should be on.  am i misunderstanding this?

nevertheless, per your advice, i have updated to 21.0.24.

i will re-experiment to see if that changes anything.  if so - no news is good news, if not - stay tuned.

thanks for reply.

[glynor]

I've seen very similar behavior to what you're describing and here's how it works:  you turn off your NAS, and autoimport (sooner or later) notices there's been a "change" to the source.  It attempts to scan the (now missing) NAS drive, finds no files, and proceeds to remove some (or all) of the broken links depending on how much time it has to work.  When the NAS is turned back on, autoimport detects new files in the watched location (because the old ones have been removed) and reimports them looking for new cover art online(replacing the old cover art).  

This is subtly incorrect, and while the net effect is the same, I thought it was worth explaining.

If you have Fix Broken Links set to Yes (the vanilla, non-protecting version) then what mwillems described is absolutely correct.
However, if you have it set to Yes (protect Network Drives) then it is subtly different, but with some NAS devices (and some computer setups) the net effect is identical.

With the protect network drives option enabled, then MC won't "fix" broken links that are missing because the entire volume is missing. That's what it does to protect network drives! The rule is, essentially:

* If MC cannot "see" the volume the media files are stored on at all, the files are protected.
* If MC can see the root of the volume the media files are stored on, and the files still don't exist, then they are determined to be "broken" and so are removed.

That sounds brilliant, and should protect most network drives. Unfortunately, with some NAS devices, they're... Slow, and act funny when they're booting up (or "un-sleeping" themselves). Often on these devices, what happens when they're booting up is that the shares become available before the filesystem that backs them is available (the disks haven't spun up or been mounted yet, probably). So, from MC's perspective, this falls into case #2 described above. The share is there, the OS has mounted the volume, but it is empty. It only stays empty for a short while, but that doesn't matter... MC can remove broken links extremely quickly (10s of thousands in fractions of a second). With some tagging changes, MC has to write changes to the disk (to the files) and that's slower. But when it is operating only on the Library (which is loaded in RAM)? Yeah, removing records from the Library is fast. I mean, really, really, really fast.

It could be improved in a few ways, I think, but it also only impacts some people some of the time with some NAS devices (or storage schemes)... And, there is a solution. The recommendation is if you have a troublesome NAS, to disable Fix Broken Links. Done.

This won't help you on OSX, but if you do have to disable Fix Broken Links, but you need the feature (or fancier options), I wrote a command line tool called MCFileRemover which can automatically remove broken links, and even delete files from disk, based on a Playlist in MC (which can be a Smartlist and so automatically generated). Unfortunately, it is Windows only.

I'd love to, at some point, make cross platform versions of my tools. They're written in C# which can be compiled on OSX but... They're currently all written against MC's COM interface and not MCWS. Only Windows has COM. So, I'd have to convert my entire underlying MC-connecting-framework over to MCWS. I've started this project but... Wow. Its a pile of work.

JRiver has a C# MCWS library. I've bugged them a few times that they should clean it up and open source it, so that others can more easily write cross-platform plugins using a nice, modern programming language. But, they're C++ nerds (and would probably say to my suggestion that C# is "nice" that I don't know what I'm missing) and so... low priority.

There's just so much to do. Progress, however, comes incrementally, but relentlessly with these guys. All things in good time.

[mwillems]

This is subtly incorrect, and while the net effect is the same, I thought it was worth explaining.

If you have Fix Broken Links set to Yes (the vanilla, non-protecting version) then what mwillems described is absolutely correct.
However, if you have it set to Yes (protect Network Drives) then it is subtly different, but with some NAS devices (and some computer setups) the net effect is identical.

With the protect network drives option enabled, then MC won't "fix" broken links that are missing because the entire volume is missing. That's what it does to protect network drives! The rule is, essentially:

* If MC cannot "see" the volume the media files are stored on at all, the files are protected.
* If MC can see the root of the volume the media files are stored on, and the files still don't exist, then they are determined to be "broken" and so are removed.

That sounds brilliant, and should protect most network drives. Unfortunately, with some NAS devices, they're... Slow, and act funny when they're booting up (or "un-sleeping" themselves). Often on these devices, what happens when they're booting up is that the shares become available before the filesystem that backs them is available (the disks haven't spun up or been mounted yet, probably). So, from MC's perspective, this falls into case #2 described above. The share is there, the OS has mounted the volume, but it is empty. It only stays empty for a short while, but that doesn't matter... MC can remove broken links extremely quickly (10s of thousands in fractions of a second). With some tagging changes, MC has to write changes to the disk (to the files) and that's slower. But when it is operating only on the Library (which is loaded in RAM)? Yeah, removing records from the Library is fast. I mean, really, really, really fast.

It could be improved in a few ways, I think, but it also only impacts some people some of the time with some NAS devices (or storage schemes)... And, there is a solution. The recommendation is if you have a troublesome NAS, to disable Fix Broken Links. Done.

Glynor, I respectfully disagree.  What you describe is how the feature is supposed to work, but I've seen "protect missing drives" dump entire libraries that were on network drives that were mapped but not connected at all (like on a different LAN so completely inaccessible), and I've even seen stuff get dumped that was on a local external disk that had been unplugged from the machine!  Presumably in those cases the OS is still reporting a drive root available and JRiver doesn't know the destinations below the root are unreachable. It's not a question of misbehaving NAS's, the "protect missing drives" logic just isn't currently reliable if you have drives that aren't always connected (or at least hasn't been for me, and we see users with related issues cropping up monthly).  In my experience, it's a pretty unpredictable setting if your machine will ever be disconnected from the media files.

Changing fix broken links to "No" is the 100% solution, we agree about that though.  It's one of a handful of defaults that I change as soon as I set up a new MC instance.

[glynor]

What you describe is how the feature is supposed to work, but I've seen "protect missing drives" dump entire libraries that were on network drives that were mapped but not connected at all (like on a different LAN so completely inaccessible)

I was describing the way it is supposed to work, at least as it was explained in long-ago-and-far-away threads on the subject. I do strongly suspect that in all cases of failure, that under the covers what is happening is what I described.  The OS says the volume is there and mounted, but it does not contain the relevant files. This probably happens under a variety of circumstances. I'm sure it is not foolproof in a bunch of ways.

But, I admit, I have it set to No, and have had it set that way for years, so I can't really comment on how effective it is at protecting network and external volumes. It tries. If it fails for you, you have two basic options:

1. Ignore it and just let Auto-Import "un-fix" those files when the drive becomes available again. This actually does work, since it "undeletes" the files when they're re-imported. The biggest issue is that [Date Imported] gets bumped, so if you need that to stay accurate, you can't rely on this. This is also probably not so good with a big library, because it might take quite some time for it to do all of this fixing and unfixing business.

2. Restore from an automatic Library Backup the first time you get bitten, and then turn it off.

[glynor]

i guess you're referring to bug #4.  i already fixed the misnamed tracks, but i can re-describe the problem.  for the cds that have this problem, when they were imported the name of the first track was not diagnosed correctly.  instead of the true name showing in the list of tracks (in the bottom window) when an album is selected, the 1st track is named simply 'track 1'.  all other tracks are correctly named.
regards

I've seen this before, but I think it was a long while ago. In any case, I have not seen it anytime in the recent past, and I suspect the bug, whatever it was, was quashed in more recent builds.

If you see it again and can reproduce it, please provide details and logs and maybe even copies of the files.

For the record, as long as your files have a reasonable file naming scheme, Fill Properties from Filename should make short work of fixing the offending file, in many cases (except when MC is ripping the files and also names them incorrectly, though I don't know that I've seen that).

[JohnT]

JRiver has a C# MCWS library. I've bugged them a few times that they should clean it up and open source it, so that others can more easily write cross-platform plugins using a nice, modern programming language. But, they're C++ nerds (and would probably say to my suggestion that C# is "nice" that I don't know what I'm missing) and so... low priority.

I'm not aware that we have a C# MCWS library.  Are you referring to something that is a part of JRemote?

[glynor]

Are you referring to something that is a part of JRemote?

Yeah. If I'm not mistaken, JRemote is written in C# and compiled to iOS using Xamarin. So it must have some kind of MCWS connection pieces. I don't know how separate from the rest of the code it is, of course. Hopefully, it was component-ized fairly well and could be made more general.

[zombie-wmd]

What version of MC are you running?  Did you try the one from a thread near the top of this board?

greetings -

i have manually updated to the latest and greatest, 21.0.24.  bugs still persist.  to reiterate and expand -

bug #1 - specifying that only the Media Server should be started still results in both the Media Center and Media Server being started.  don't know if this is a clue or not, but looking at my login items in system preferences the app 'MC Application' appears in list.  this is true whether it is specified that only Media Center, or only Media Server, or both should be started.  bug #1 is easy enough to confirm.  bug #1 has a direct bearing on bug #2.

bug #2 - Media Center prevents OS X from shutting down.  upon further experimentation i have discovered a deeper truth.  shut down proceeds normally if only Media Center is running or if only Media Server is running.  when both are running then shut down is prevented.  one can witness this happening.  when OS X is shut down, the Media Center icon disappears from the dock, but the Media Server icon stays in the menu bar.  OS X is prevented from shutting down and the OS X MsgBox about 'shut down being prevented' is displayed.  selecting 'try again' results in OS X shutting down without any further complaints.  because of bug #1, i couldn't directly test what happens when only server is running, but i addressed it in another way.  i let both come up, manually shut down Media Center and then manually shut down OS X.  shut down was not prevented. in the past, stalwart beta testers have tried to recreate this bug and couldn't.  i suspect that it was because only Media Center running during the test.  again, bug is easy enough to confirm.

new bug - since i had to manually update from 21.0.4 to 21.0.24 and 'Help->Up Channels->Disable Automatic Update' is not set, it seems that automatic update is not working.

my impression is that MC under OS X is a work in progress.  i believe these are heretofore undiscovered bugs.  please advise.

BTW - it seems that most posts and responses deal with issues around how to use the product.  as always, responses are timely and knowledgeable. many thanks for past help; this forum probably is a big part of MC's success.  i am assuming this is the proper venue to report bugs.  if there is another, more formal avenue for bug reporting/tracking, please advise.

regards

[JimH]

If you find a bug that is clear and easily reproducible, please post it in the thread that announces the build (near the top of this board).

If it is a problem that requires discussion, please start a thread with an appropriate title.  You can add a link to it to the build thread.

Laundry lists of problems don't get much attention, especially if the problems are buried along with discussion or feature requests.

Please include the version of OSX that you're running.