Print

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

[Vocalpoint]

Recently moved my master FLAC library to a new location on our HTPC. Had been accessing it from our "server" location for the last 3 years.

After the move was complete (RM&C tool rocks BTW this week I have been experiencing some very annoying audio dropouts on the track that is playing when I make album art changes to another album in the collection.

Both PC's have very robust Intel network cards, current drivers and are operating at a full 1GB throughput. I have no AV on the HTPC or anything else that should be interfering.

Is MC incapable of playing a single song over the network while I make changes to other files on the same source PC?

My MC buffer is set to 25ms (this was set at install - have not changed anything yet). And I am playing to my Teac UD-501 via USB. (Maybe a USB/NIC conflict on the mobo?)

Appreciate any other thoughts on what is going on...

Cheers!

VP

[Dawgincontrol]

Curiosity; are you playing tracks from memory or not in your setup?

[Vocalpoint]

Curiosity; are you playing tracks from memory or not in your setup?

Not playing from memory currently. Did not play from memory when I was accessing source files from the former location either.

Do not recall having any issues as I play music and edit album art daily.

Shall I turn it on and try?

VP

[blgentry]

I've seen this behavior a lot on the Mac version of MC20 and MC21. 

I'm not very educated on audio setup on MC for Windows.  The buffer size you mentioned would be teeny tiny if it was on a Mac audio device under MC.  Do you have selections for other much larger buffer sizes, like 250 or 500 mS?  If so, try at least 125 mS, though I really suggest 250.

This might be COMPLETELY off base.  Just sharing my experience.

Brian.

[Vocalpoint]

I've seen this behavior a lot on the Mac version of MC20 and MC21. 

I'm not very educated on audio setup on MC for Windows.  The buffer size you mentioned would be teeny tiny if it was on a Mac audio device under MC.  Do you have selections for other much larger buffer sizes, like 250 or 500 mS?  If so, try at least 125 mS, though I really suggest 250. This might be COMPLETELY off base.  Just sharing my experience.

Brian,

Agreed.

However - this setting is not one I have ever changed (to my knowledge). Also - the setting was part of my library backup that I restored into this new build. So it's sitting at 25 - while I see the "recommended" size is 100. Will try that as a test.

Cheers!

VP

[Dawgincontrol]

Not playing from memory currently. Did not play from memory when I was accessing source files from the former location either.

Do not recall having any issues as I play music and edit album art daily.

Shall I turn it on and try?

VP

It's worth a try.  In different versions it cured a problem I had.

[Vocalpoint]

It's worth a try.  In different versions it cured a problem I had.

Switched over to Play From Memory AND adjusted MC to use my ASIO variant of the UD-501 driverset (there are both WASAPI and ASIO options). Buffer is 50ms - and still no joy.

The dropouts seem even worse with this combo.

Get nasty dropouts when clearing art from an album and then again when adding new art to the same target. Sigh.

VP

[blgentry]

Again, I'm speaking from experience on the Mac side, not Windows, but...

Even 100 mS is too small to prevent interruptions on a my Mac.  I need at least 250 mS of software buffering for it to be acceptable.  Is that kind of buffer out of the norm for an ASIO driver?

Brian.

[Vocalpoint]

Even 100 mS is too small to prevent interruptions on a my Mac.  I need at least 250 mS of software buffering for it to be acceptable.  Is that kind of buffer out of the norm for an ASIO driver?

Brian,

If you check that screencap - the setting of "50" is what is recommended by JRiver. Now - that does not mean it will always work - but it seems like a reasonable starting point.

However - I have another theory here - and it may have something to do with IRQ contention on this new box I built.

The network card is in it's own PCI slot but I am betting dollars to donuts that the USB port I have my DAC plugged into - is sharing a PCI lane with the network card. If that's the case - and network card and USB are jamming the PCI lane with a ton of traffic all at the same time - dropouts are a likely scenario.

I have dealt with this before on my recording machines in the studio. Must make sure that all "devices" (especially the audio card) have a much PCI lane space as possible (ideally sharing no IRQs) to avoid be affected by another device on the same lane.

I need to study the slot I have that network card in - vs which USB port is in play.

Will report back.

VP

[Vocalpoint]

More info on this issue....

Today I was playing tracks from my local drive - while changing cover art on an album on the network - and the same dropouts occur. So this tells me that it has to be the network card conflicting with the USB that my DAC is plugged into - conspiring to cause problems.

I had always thought - it had to be a track streaming over the network while I was editing art on an album over the network that would cause the contention - but it's clear now that if a local file suddenly has drop outs - the network card is not in play for the local playback - yet we get dropouts when messing with art on a network target.

Time to get hands dirty with card slots etc etc.

VP

[blgentry]

If you want to, this is a good experiment to confirm your theory.

Play music from MC, using a local file (not on NAS).
COPY a large file (or folder full of files) from one location to another on the NAS drive.

Do dropouts happen?

Brian.

[Vocalpoint]

If you want to, this is a good experiment to confirm your theory.

Play music from MC, using a local file (not on NAS).
COPY a large file (or folder full of files) from one location to another on the NAS drive.

Do dropouts happen?

Brian.

Hmm. Interesting. Playing local FLAC file in v20.0.132.

Copied a 1.5 GB file to our Public folder on the server. No dropouts.
Copied the same to the actual HTPC share (on the LAN) - where all our media is - no dropouts
With file still playing from local drive  - changed art work on a 10 track album that resides on the HTPC (LAN) Dropout city.

So it seems this has nothing to do with the NIC or even the network. But it has everything to do with MC now.

What is going here? Seems that MC cannot play a local file AND manage the changing of an embedded image to files on the network - at the same time.

?

VP

[blgentry]

All of my files are local.  Yet I have seen the same behavior:  Play local files with MC.  Change album art on some files in MC.  Get some dropouts.

As I said before, increasing my buffering settings seems to have fixed this for me.  Have you tried a MUCH larger software buffer?  Start with 125 mS, or go big and try 250.

I just tested my system by replacing cover art on three albums (one at a time) while playing and got no dropouts.  Again, I'm on a Mac, so this might not be exactly the same thing.  It just seems too similar to not be related in some way.  During my months and months of battling dropouts, changing album art was a fairly reliable (but not 100%) way of inducing dropouts.

Brian.

[Vocalpoint]

All of my files are local.  Yet I have seen the same behavior:  Play local files with MC.  Change album art on some files in MC.  Get some dropouts.

So yours is happening when playing local AND changing art on local files? This is clearly a problem with MC then.

VP

[blgentry]

So yours is happening when playing local AND changing art on local files? This is clearly a problem with MC then.

Yes, all files are local.  I have a few files on a USB drive, but it's direct attached via USB3.  I have nothing on NAS drives.  For some reason I feel the need to mention this again:  I'm running MC21 for Mac OS X.

Brian.

[Arindelle]

Just out of curiosity, are you guys storing artwork with the album, or lumping it all on the system drive?  Is your import options set to rebuild thumbnails? And is the autoimport set to run all the time?

Can't see why memory playback or even latency settings would have anything to do with this, but I'm really just guessing.  But constantly rebuilding thumbnails might temporarily hang the program, especially on large libraries with big embedded images.

The only time I've had problems like you described is when I had a NAS (a slow one) and artwork not being in the file folders. Might want to test without rebuilding thumbnails and getting artwork in the album folders, maybe auto-import off too ...  just to check.

[Vocalpoint]

Just out of curiosity, are you guys storing artwork with the album, or lumping it all on the system drive?  Is your import options set to rebuild thumbnails? And is the autoimport set to run all the time?

For me...

MC Version: 20.0.132
OS: WIndows 7 x64
Audio: ASIO (Teac UD-501 via USB)
File Type: FLAC
File Location: Media resides on \\MEDIA-PC\Music (On the LAN)
Artwork: Embedded - in each and every file.
Import Options: Manual on this workstation
Build thumbnails - Off everywhere that I can think of
Autoimport - OFF except on HTPC as above (but dropouts occur on demand - not when the HTPC is importing anything)

Like you - I am at a loss to understand how I could be playing from memory (which you would think would be a completely walled garden that MC would make isolated from anything else) and then have MC start failing to deliver the audio stream while doing file management. I also do not understand what latency settings have to do with this either.

Something is going on - and not in a good way - when MC is processing audio AND updating the target FLAC files AND presumably it's library files (local c drive) all that the same time.

My dropouts happen when artwork is stripped (right click on album on HTPC and choose Remove Cover Art) and then again when I choose Add From file. As soon as MC starts any type of file write (remove or add)to the FLAC file - the audio starts glitching away like it cannot handle itself.

I would have though this program after 20 iterations would be able to write some images "over here" while playing audio over here without a hassle factor.

Or am I to assume that every other MC user on the planet makes sure nothing is playing when they do their album art stuff?

VP

[Arindelle]

My dropouts happen when artwork is stripped (right click on album on HTPC and choose Remove Cover Art) and then again when I choose Add From file. As soon as MC starts any type of file write (remove or add)to the FLAC file - the audio starts glitching away like it cannot handle itself.

ah, ha.  I never remove cover art, I just replace it ! .. maybe there is some glitch in the remove art tool?? Maybe thats the problem? I'll try to use the remove cover art tomorrow to see if I can reproduce the issue and get my system to mess up playback

Can't see why you need to remove art anyways. I'd try just highlighting the tracks, copy it from the web and then pasting the art in (or loading it from a file works too)  ... even if I'm changing the art on a track I'm currently listening too, it just won't write to the file until its done.  Try it and see. Thats why I think it has nothing to do with memory or latency at all. Probably shouldn't change those settings anyways as they are probably set-up optimally for normal playback.

I like to keep a folder.jpg copy in the album folder (not required of course) so afterwards I just use the option to copy the art to "location specified in options. I'd also check in your options to make sure it is not writing any art to the system drive without you being aware of it. But doesn't sound like that has anything to do with it looking at your config, VP.

If this still bugs your playback, I'd try turning off the HTPC auto-import (its the machine running media server thats important). Regardless this type of operation is one of those that isn't supported from clients anyway as I'm sure you know already .... as that has to be done from the media server machine, (I use Teamviewer when I want to do this remotely).

[Vocalpoint]

Can't see why you need to remove art anyways. I'd try just highlighting the tracks, copy it from the web and then pasting the art in (or loading it from a file works too)  ... even if I'm changing the art on a track I'm currently listening too, it just won't write to the file until its done.  Try it and see. Thats why I think it has nothing to do with memory or latency at all. Probably shouldn't change those settings anyways as they are probably set-up optimally for normal playback.

It's always been a "completest" thing with me When I change album art - the old has to go before the new goes in. So I remove everything to be sure and then lay in the new stuff. And yes - I am aware that MC will not write to the file that is currently playing - but that's not what I am doing. I am playing a track either from the network location OR my local drive - that has nothing to do with the art I a going to change. While this track is playing - if I go to a completely unrelated album and change it's art - it's glitch city.

I ran some logging against this process (dropouts/glitches) and MC reported NOTHING with respect to any interferance with the actual audio stream throughout the entire logged event (changing artwork on a selected album in the library). I did notice some real weird stuff going on when the art was about to be added to the file:


0012527: 4544: General: CFileInfo::ImportCoverArt: filename=D:\Pictures\To Be Filed\XTC - The Big Express (1984).jpg
0012527: 4544: General: CFileInfo::ImportCoverArt: Finish (0 ms)
0012527: 4544: General: CFileInfo::Close: Start
0012558: 4296: Reader: CWinINetReader::Open: Start
0012558: 4296: Reader: CWinINetReader::Open: Opening http://www.yadb.com/cgi-bin/CoverArtExists.cgi?High=3386185246&Low=430839612
0012558: 3796: Reader: CWinINetReader::Thread: Start
0012558: 3796: Reader: CWinINetReader::Connect: Start
0012558: 3796: Reader: CWinINetReader::Connect: Finish (0 ms)
0012558: 3796: Reader: CWinINetReader::DownloadFromHTTPURL: Start
0012745: 3796: Reader: CWinINetReader::DownloadFromHTTPURL: Success
0012745: 3796: Reader: CWinINetReader::DownloadFromHTTPURL: Finish (187 ms)
0012745: 3796: Reader: CWinINetReader::Thread: Finish (187 ms)
0012745: 4296: Reader: CWinINetReader::Open: Finish (187 ms)
0012745: 4296: Reader: CWinINetReader::Read: InternetReadFile returned true with zero bytes read: EOF
0012745: 4296: Reader: CWinINetReader::Close: Start
0012745: 4296: Reader: CWinINetReader::Close: Finish (0 ms)
0012745: 4296: Reader: CWinINetReader::Open: Start
0012745: 4296: Reader: CWinINetReader::Open: Opening http://www.yadb.com/cgi-bin/CoverArtSubmitFile.cgi?High=3386185246&Low=430839612
0012745: 4284: Reader: CWinINetReader::Thread: Start
0012745: 4284: Reader: CWinINetReader::Connect: Start
0012745: 4284: Reader: CWinINetReader::Connect: Finish (0 ms)
0012745: 4284: Reader: CWinINetReader::DownloadFromHTTPURL: Start
0013198: 4544: General: CFileInfo::Close: Finish (671 m

MC preps the target file for write access and then ducks out to the internet (YADB) for some bizarre reason before finally writing my image to the file. What exactly MC needs to be going to YABB for during this process is concerning to me. I am writing my own images to my own files and I do not see any reason or point to go to YADB to "check" for something.

This bizarre process uses my network card too - making for even more possibility of contention. Not to mention a privacy or rights issue as well. Is YaDB taking a copy of my artwork without telling me? Looks like it might be with a file named CoverArtSubmitFile.cgi?

I would like more information on exactly what the Add From File process is doing - becuase this does look a little weird. I would expect the process to open my file, write my image and get lost. Not venture out to the internet everytime I want to add some art for MY music files.

That aside - during this log period - MC was glitching constantly as the image file was being written to the 10 tracks for this album - but the log records no oddball behavior for the dropouts. Which tells me the MC is not even aware that it's glitching. Making this look more and more like a hardware (IRQ) issue as before.

Will keep on digging - but I do not like the look of that YaDB stuff in this log.

VP

[Vocalpoint]

Another update.

Noticed that I can have a track playing from the network library and then change/edit/add artwork to a local file - with NO dropouts.

So this issue is squarely within the realm of the network card (which is probably sharing IRQ with my USB port in this case) that is causing the problems.

I am going to examine my USB today and switch a few things around and see if hardware is really the concern.

VP