Print

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

[marko]

Image Playback

Files are on a mapped network share, mapped to match the location sent by the served library. To test, I also imported all the photos into a local library (leaving the files in their networked location). The results were the same.

Highlighting "Slideshow" in Theater View and pressing OK it takes between 7 to 10 seconds for playback to begin. Each slide is set to last 5 seconds. The duration slider goes up to 4 out of 5 seconds, then hangs there for anything between 7 to 10 seconds before showing the next slide. To remove any complications, I emptied the caption setting under Image Display (btw, if this is empty, I think that no OSD being displayed is way better than an empty one).

I then moved some files onto the HTPC itself and imported these. These files playback properly without any hanging between each one. Network issues? I don't think so. Audio files played over the same network do not exhibit this hanging, even crossfading works just fine, as do video files. The attached log shows me starting MC (directly into theater view) starting a slideshow, watching 3 or 4 images, then closing MC, maybe it has some clues?

FWIW, the same fifteen files, on the network location, play back in a full screen slideshow without a hitch if I use the Windows Picture Viewer.

Turning off Microsoft Security Essentials Real Time protection makes no difference to this behaviour.

[Matt]

Are you playing on a Library Server client?

What happens if you reduce the setting in Options > General > Video card?

Can anyone else reproduce this?

Thanks.

[MrC]

I just tested this, no troubles.

MC running in Parallels, Windows 7.  Both server and client have MSE.

Slideshow started within a second or two, playback and progress bar are fine.

[MrC]

Marko,

Have you added the share drives to the list of Excluded directories?

[Matt]

On a wing and a prayer, you might try 154 or newer.

Also, when image playback is slow, could you push Pause/Break on the keyboard and report what the frame rate display is showing?

[marko]

Testing using 154 (I always use the latest builds)
MC is a library server client. Image conversion options are set to none.

Options > General > Video Card was set to highest. I took it down one notch, navigated to my fifteen test files, and they played back fine. I was like WOW!
I then went to my "Recent Photos" view and asked for a slide show of just over 7000 photos. The hanging was back. I went directly back to my fifteen test files, and now they were hanging too.

I tried all flavours of "Video Card" settings, and nothing would stop the hanging.

I had not added the shared drives to the list of exclusions in MSE. To be honest, I have never touched the MSE settings, just installed it and let it do its thing. It has never got in the way before, and does not prevent the Windows Picture Viewer from playing a smooth slide show of the same networked image files. For completeness, I added the mapped drives to the exclusion list, and it still hangs.

"When image playback is slow"...
MC appears to be hung. So, when the progress bar gets to "4 out of 5 seconds" it stops, and MC hangs for anything up to 10 seconds. If I press the "Stop" button, MC will not respond to that until it has opened the next image, then it will stop. I don't think it's a 'playback is slow' issue, it's a "getting the next image" issue.

I went in search of the "transition" settings, thinking that they might be causing my issue, but they seem to have gone? When MC finally gets the next image on screen, there is no transitioning, it just appears.

There is no "Pause/Break" key on my dinovo mini. Taking the above into account, let me know if you want me to break out a full keyboard and test this. My gut tells me that while it's hung at 4/5 seconds, the pause/break key will do nothing, then MC will finally get the next image up, pause/break will then fire, and the frame rate will be quite normal.

-marko.

[JimH]

Maybe you said, but are the files local?

And are they really big?

[marko]

Forgot to say, in frustration, I once again uninstalled MC, removing all registry and library files, and reinstalled.

Every setting is now on default, it still hangs

I tested with the following...

Library server client and networked files - Hangs between images
Local library and same networked files - Hangs between files
Local library and same files copied locally - No hanging

The jpg files from my Nikon are around 10 Mb a pop, while the ones from my old Kodak are only 1 or 2 Mb each. I tested with samples from each camera and they both hang.
The big Nikon files have never been a problem before.

[Matt]

If it's only slow when the files are on a network, doesn't that seem to point to a network read speed issue?

I think we pull the entire file in one read to memory for images.  Playback doesn't thread the load unless it's a URL, because normally a local file loads fast and it looks smoother not to show a loading in thread message, and then display the image right after.

[marko]

If it's only slow when the files are on a network, doesn't that seem to point to a network read speed issue?

That's what I thought too, but then, why has it never been a problem before, and why is it not a problem for MC when playing back audio or video over the same network, and why is it not a problem for Windows Picture Viewer to show a full screen slide show of the same networked files?

[JimH]

Can you test from another PC on the LAN?

[marko]

Hmm, good thinking...

The only other machine I have is my wife's pretty weak laptop... I'll give it a go though...

[Matt]

I just tested image playback of JPEG files from a network share.

The 'I/O Read Bytes' in Media Center went up 13.4 MB when I played one.

This corresponds to the size of the image played (which started fast), and the previous and next image which get queued up in a low priority background thread.

So I'm not seeing any unexpected I/O with JPEG.

It's possible Nikon RAW could be slower, because we aren't directly doing the I/O.  Could you test JPEG?

[MrC]

I had not added the shared drives to the list of exclusions in MSE. To be honest, I have never touched the MSE settings, just installed it and let it do its thing. It has never got in the way before, and does not prevent the Windows Picture Viewer from playing a smooth slide show of the same networked image files. For completeness, I added the mapped drives to the exclusion list, and it still hangs.

FYI - MSE uses heuristics for network data.  You'll want to ensure that both client and server side shares are excluded.

Remember, A/V scanners are not static beasts - they are constantly in flux, and with heuristics, rules, and patterns being ever-updated, what worked in the past, or works for some other app, isn't often useful for comparison.

Is there anything else I can try here to help reproduce (or not)?

[marko]

I try to be as accurate and informative as possible when reporting these things.

We are only talking about jpg files here. MC does not deal with any of my RAW files.

MrC, thanks for the 'exclusion' advice. I have added them, but the problem persists.

Now, the kicker...
I've just installed build 154 on my wife's laptop, connected to the same served library, using "wireless g", and slide shows are as smooth as a baby's butt, and that's with the big Nikon JPGs too. That laptop also has MSE installed, running with default settings and no exclusions.

I guess this points to some issue on the HTPC, but where to start looking...
For example, it took MC several seconds to load the served library on the laptop, using the slow "g" wireless network, while it loads in a blink of an eye on the HTPC, using a wired connection. All other media types play (read, advance to the next file) just fine on the HTPC, I'm only seeing this issue with jpg files, and apparently, only when viewing using MC.

I'll try some more trouble shooting over the weekend, but am almost out of ideas. If anyone can think of any specific area that might be worth focussing on, let me know. Bear in mind that both the laptop and the HTPC are currently using the same default MC settings and the same served library, suggesting that there is no issue there. ?

[JimH]

Try using the laptop to serve files to MC on the HTPC.  That might tell you something.

Try just plain copying files from the network drive to the HTPC.  Try multiple times.

Have you updated the firmware for the network drive?

[JimH]

I try to be as accurate and informative as possible when reporting these things.

Your reports are excellent.  You may win a Pulitzer Prize some day.

[leezer3]

Have you tried updating the wireless card driver recently, from the manufacturer not Windows update?
Sounds to me like it's choking out on trying to request large numbers of relatively small files

A Wireshark capture from a MC slideshow and a Windows slideshow might also be interesting.

-Leezer-

[marko]

Your reports are excellent.  You may win a Pulitzer Prize some day.

Perhaps it's just that while I try to be as accurate and informative as possible while trying to solve an incredibly frustrating problem, some well intentioned replies serve only to demonstrate that sometimes, people simply don't read my accurate and informative information

Here's a recap, and the latest news:

I completely ran out of ideas. Nothing I tried would make this work on the HTPC, so, yesterday, I clean installed Windows 7 x64, ran all the windows updates, turned off windows defender and UAC, installed build 156, loaded the served library... problem still exists

MC is at all default settings. There is no antivirus/antimalware software running. Windows 7 x64 clean install plus Windows Updates.
The network locations have been mapped to the HTPC so that filenames on the HTPC match those served by the library. This appears to be working correctly as there are only thumbnail requests in "Media Network" output list for Media Server. There is absolutely no issue with playing the next file with audio or video, this problem is purely image related. All of these image files are excluded from scanning by the server PC AV software, along with all MC related directories.

The HTPC is wired to the router. I unplugged the cable and tried a wireless n connection... problem still exists. The wife's laptop can connect to the same served library using wireless g and the slide show is flawless. I've switched the HTPC back to a wired connection.

I created a new library on the server and added all the image files to it. The problem still exists on the HTPC.
It does not matter about file size. The problem is the same with 10 Mb jpg files or 14Kb png files.

I tried adjusting the slideshow duration. I set it at 20 seconds, and the problem is still the same. It gets to 19/20 seconds, then hangs for 7-10 seconds before displaying the next image, regardless of size.

I tried setting the video card option in "General" from "Automatic" to "Mobile hardware". Problem still exists. I set it back to "Automatic".

It would appear that I first noticed this problem back in the build 143 thread, where I posted:

Theatre View
When starting an image slideshow, the first image shown does not get a caption displayed.
I think there's something off with the slide duration setting. I've set mine to seven seconds, but it's more like 12 or 14 on screen.

File transfers between the server pc and htpc are nice and zippy. No apparent issues there, tried it with one huge file and again with lots of little ones. The little files happen too fast to get a reading, but the big ones go across at around 53 Mb/s

No firmware updates on any drives, no.

I'll try copying some files to the laptop and serving them from there tomorrow, I've spent enough time on this this weekend already.
I've had a quick look at a wireshark demo video. It captures packets. Will it highlight any network delays? if the answer is no, then it's not the tool for me. I'm also guessing that if there is a network delay, it has to be at the htpc end, picking up the server responses, as there are no issues for the laptop connected to the same library over the same network.

The log file that I captured in the first post appears to have gone unread. Does it contain any clues for me to follow up on?

-marko

[Matt]

I'm going to have to add more logging.  I don't think it's reading the file that's slow because there's a 10 second pause between when it starts playing the next file and when it actually sends the play command to the playback engine.

[marko]

There isn't a "slow" file. MC is hanging for ten seconds or so with one second to go at the end of each and every slide. I've been checking this by moving the mouse around the top of the screen to keep the player bar visible. Everything will lock up until the next file finally displays, and so on...

Now, the good news...
I think I have this one solved, but don't understand the solution on a couple of fronts.

Open to anything, and unable to wait until tomorrow, I followed Jim's tip to try serving some files from the laptop... no hanging files. Just a little lagginess that I expected from the wireless roundabout. No hanging... what???

This made me turn my attention back to the server PC... here, the jpg files were showing up in the AV activity monitor as MC was accessing them, despite the exclusions being in place correctly. Removing and re-applying the exclusions has fixed that. How did it come to be ignoring my settings in the first place? I've no idea. It's been installed for over a year now and since setting it up, I've never needed to bring it out of the system tray. It's set to automatically update definitions and software modules as needed and never bother me... so I'm surmising at the moment that an update caused this. I can't know, for sure, but will keep a wary eye on it for bit.

I can reliably reproduce the effect on the htpc by adding or removing an exclusion rule. What I don't understand is, when MC accesses the same files, over the same network, slide shows work on the laptop without hanging, regardless of the exclusion setting, it just makes no difference there... why would that be? or perhaps more importantly, why does it make a difference on the htpc? and why doesn't it make any difference to the Windows Seven Picture Viewer?

Confusing, or at least, to me it is. Thanks to Jim for the pointer that finally got me on the way to a solution.

-marko

[JimH]

** Virus Checker !!

 

You're welcome Marko.  Good to see it behind us.  Darn computers.

[marko]

Behind us in as much as I appear to have a solution, yes. Should we just leave it at that, or should we be trying to answer the questions that remain...

Why is MC running on the laptop not affected when accessing the same files over the same network, from the same MC server? (or "Why is the htpc affected?)

Why, on the htpc, is MC affected by this, but Window Picture Viewer is not?

Is there anything to be gained from knowing these things? I know they cause issues, but "add an exclusion to your virus checker" is never a popular answer, and here, the same build of MC is reacting differently to the same scenario on two different systems...

-marko

[JimH]

I'm going with this is completely a virus checker problem.  It was set to bypass local files but check network files.  Nobody likes to hear it, but virus checkers cause a lot of problems like this.

[marko]

It was set to bypass local files but check network files.

Not quite...

the jpg files were showing up in the AV activity monitor as MC was accessing them, despite the exclusions being in place correctly. Removing and re-applying the exclusions has fixed that.

There is only one exclusion list. I simply removed the location, okayed out, then went back in and re-applied the same exclusion. This part of the equation is absolutely 100% "virus checker problem". The "Laptop vs htpc" and "MC vs Windows picture viewer" questions are not so black and white.

I'm not pressing for answers or explanations, it's just that the variations in behaviour were confusing and seriously muddied the waters, and can't really be completely written off as 'virus checker problems'. They should at least remain 'on the table' so to speak, as they may prove useful questions to someone else in the future.

[MrC]

I know you're likely busy, but to un-muddy the waters, uninstall MSE from the involved systems and reboot, and test again.  This is the only way to be conclusive; unfortunately, A/V checkers are just that complex, unpredictable, and meddlesome.

[Matt]

I know you're likely busy, but to un-muddy the waters, uninstall MSE from the involved systems and reboot, and test again.  This is the only way to be conclusive; unfortunately, A/V checkers are just that complex, unpredictable, and meddlesome.

True.

Avast was breaking basic Wininet calls on my dad's machine.  And disabling it didn't make any difference, only a complete uninstall.

As for this particular case, we can add more logging to see what's slow.  But the fact remains that the man-in-the-middle software is causing something that should be fast to become slow.

My advice would be to run Media Center as user (via UAC) and exclude it from any real-time, man-in-the-middle type software.

[marko]

I know you're likely busy, but to un-muddy the waters, uninstall MSE from the involved systems and reboot, and test again.  This is the only way to be conclusive; unfortunately, A/V checkers are just that complex, unpredictable, and meddlesome.

I was testing yesterday on a htpc with a clean install of Windows Seven, with no AV software installed, and Windows Defender disabled.
The original problem is solved. The issue was being caused by NOD32 on the server PC not honouring the folder exclusion rules that had been entered.

The question that burns for me, is why did that not affect the laptop when it connected to the same server, over the same network to play the same files.

The fact that it did this, led me to believe that the problem was at the htpc end of things, where MSE was installed.
Jim's suggestion that I try using the laptop to serve the files, which worked, caused me to turn my attention to the server PC, and so find a solution.

As for this particular case, we can add more logging to see what's slow.  But the fact remains that the man-in-the-middle software is causing something that should be fast to become slow.

It's up to you Matt. Yesterday, I was able to reliably reproduce the effect on the htpc by simply adding and removing an exclusion rule to the AV software running on the server. I don't know if logging will catch anything as for me, it appears that in between images, MC is hung, completely unresponsive, for anything up to 10 seconds.
If you're interested in why the laptop was unaffected by this, and add logging to catch it, I don't mind running the tests on both systems to generate the logs.

-marko.

[Matt]

Looking at the code, I'm pretty sure the thing that's slow is our check for file permissions when starting playback.  This is relatively new.

We simply open a file for read access and then close it right away.

This should take a millisecond, but the virus software or network driver or something else on your machine is causing it to take 10 seconds.

There was an old XP bug where opening a network file and reading a little (or maybe none like this?) could cause CloseHandle(...) to be slow.  The solution was to open the file for random access, so the slowness must have been related to the Windows cache system.  An interesting tidbit is that this exposed another bad bug in Vista x64, but I won't go into it.

Anyway, I'll try opening the file for random access when checking permissions.  This will be in 16.0.158.  Let us know if it helps.

Thanks.

[marko]

The answer to "Why is there no hang on the laptop" is "It has no mapped network shares, therefore it is not accessing the files directly, it's getting them via the library server"

Without the exclusion for the image files folders, it still hangs. Interestingly, audio and video do not hang, only images.

I've added the exclusion back in at the server end which allows smooth slideshows on the htpc. I'm OK with that if you want to leave it there.
I've attached a new playback log with the hangs.

-marko

[Matt]

The code that's slow is incredibly simple:

Code: [Select]

HANDLE hFile = CreateFile(fnFilename.GetFilenameForUseWithOperatingSystem(), GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
FILE_FLAG_RANDOM_ACCESS, NULL);
if (hFile != INVALID_HANDLE_VALUE)
{
CloseHandle(hFile);
}

It's pretty sad that a virus program can make that take 10 seconds.  I'm not really sure what more we could do?

[MrC]

Wonder if the scanner wants to read in the entire file first to check it, since it is being opened for random access.

[Matt]

Wonder if the scanner wants to read in the entire file first to check it, since it is being opened for random access.

A previous build didn't specify random access.  That flag was a guess I added to 16.0.158 hoping the problem was related to read-ahead caching and that the flag would prevent it.  It didn't help.

[marko]

Indeed. What to do? I've no idea, I just report the issues and try to keep you in a job

The Windows Picture Viewer must be accessing the files in a different way as it is not suffering the same issue. Playback there started by browsing directly to the files via the mapped drive and double clicking one of them, then hitting the 'slideshow' button.

There's a link to this in the "Weird and Wonderful" thread, so at least if anyone else experiences the same, they'll have an idea what to do to fix it. I've used NOD32 for a long time now, and generally, I never know it's there, it just quietly does its thing in the background without any fuss. I've never had any dealings with their customer support... Is this worth reporting to them? Do you think they would be interested enough to do something about it, or would they just blame MC and ignore me?

-marko

[MrC]

Sorry, I don't recall if this was done, and don't see it in the post.

I don't see it in NOD32's documentation, but many A/V checkers have the ability to exclude *processes* too, such as JRService.exe and JRWorker.exe.  These exclusions are necessary in some cases.

Just thought I'd note it for the record.

If you can give them a reproducible case, it might be worthwhile to report.  I wouldn't count on a pain-free process though.