Print

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

[glynor]

So, I finally took the plunge over the weekend and got MC14 all set up at home on my HTPC and other networked machines at home.  One of the features I was most excited about was the ability to use the Library Server and actually have multi-machine read/write access to the library.  Unfortunately, in it's current implementation, this feature is completely unusable for me.  I'll describe my setup (which probably isn't that unusual for using this feature):

1. All my media resides on a network RAID-5 share, served by a machine off hidden in a corner of the "office" room.  This network share is mounted as "Drive M" by all machines on the network.
2. The network is a Gigabit Ethernet network.  I also have a laptop that is used on my 802.11N wireless network (though that system isn't my primary issue or concern right now).
3. I set up MC14 on the server machine, and enabled the Library Server feature.
4. I then set up MC14 on my HTPC (and Laptop), and connected to the Library being served by the server machine.

This all works fine, and audio playback works without issue.  However, video is completely unusable with this setup.  Simply opening a file takes forever (literally minutes) with no feedback other than the HUD saying "Opening..." and once they do open, seeking is also similarly slower-than-molasses.  If I open the same exact library directly on the HTPC (the library itself is also on Drive M), video opening and seeking performance goes back to normal.  I saw this behavior with a variety of video file types, but primarily with HD x264 MKVs and MP4s.  It does also happen with standard-def XviD AVIs, though the delay isn't as extreme then (probably just due to smaller file sizes).  Most of the MKVs I tried with were between 500MB - 1.5GB in size, which is pretty standard for my library.

Now, I realize that if I'm using the Library Server feature to stream across the Internet (or some other bandwidth constrained network pipe) that there would be issues like this.  However, if I'm directly connected to the file source (Drive M) on the client machine, it was my understanding that it should work just like accessing the library files directly.  This is currently absolutely NOT the case.  When accessing the Library directly using my HTPC, and starting those same files playing back, I do get slight delays beyond what I see  when playing the files locally, but on the order of 3-5 seconds max.  Using the Library server, it was seriously like "walk away, grab a beer from the fridge, come back, sit down, open the beer, take a sip, reach over and grab my phone and pull up a website to start reading, and then suddenly it would start playing" (5 minutes was not unusual).

Obviously this isn't workable.... Any guesses on what is happening?  Right now I have to just use the old-style: access the library on the network share directly (and have the "read-only" library constant issue for any other machines that run at the same time).

[SeaDrive]

I just noticed the same thing last night when I tried to access some videos via library server. I ended up browsing to the network share directly and the video played fine.

[bunglemebaby]

This happens for me too. I'm using 14.0.19.
It's my first time using the Library Server, so I just thought that was status quo at the moment.

[Alex B]

... I just thought that was status quo at the moment.

It is the status quo and it has always been like that. The used technique has not changed.

The files are streamed using internet capable addresses and obviously most video file types need to be fully downloaded before the DirectShow filters can handle them. In addition, the system does not provide access to external subtitle files because they are not part of the served library and the filters have no means to find them. Also some referenced file types do not work properly like cue and apl audio files and DVD disc folder structures.

Only the filename field is now not converted when the library is downloaded. MC does that internally for each played file under the hood. I have noticed that this makes possible to use location based view schemes also on the client, but that doesn't make the video files more playable.

I have sugggested a couple of times that the Library Server system could have an additional mode that would use direct file access instead of converted streamable addresses. However, it could not be fully automatic similarly like the current Library Server system is. The users would need to store the media files in locations that can be accessed directly through the Windows file system on the server and on the client and create a library that uses only the shared locations.

I think Matt liked the idea the last time I posted about it, but I don't know if it is under development.

[MrHaugen]

Something has to be done with this. I stopped using library server for videos a long time ago because of this. It's a shame. I'm all for Alex B's suggestion to have a direct access to the shares. If it can be accessed directly from the client, go ahead. Otherwise "stream".

[)p(]

Something has to be done with this. I stopped using library server for videos a long time ago because of this. It's a shame. I'm all for Alex B's suggestion to have a direct access to the shares. If it can be accessed directly from the client, go ahead. Otherwise "stream".

Yes me too...I remember trying the library server while evaluating mc and almost giving up on mc for videos...then I luckily found a thread about using a shared library on a fixed network drive.

peter

[raldo]

"Good" info, I'll put off trying this for a while, then.

[rpalmer68]

In this thread http://yabb.jriver.com/interact/index.php?topic=52364 Matt said

Alex also raised a good idea: making the client not use the server at all for cases where it can resolve the filename because it's UNC or a network share.  We're going to think about this one.

and then

Supporting supporting three scenarios would be great.
1) files stored on a server.
2) files stored on a common network location.
3) files stored locally (but they are synchronized manually). Music on laptop is the most common scenario.

All of these work now.  The only requirement is that MC has imported the files so that Library Server can serve them. 

Does this mean the client "should" be pulling the videos directly from the drive/NAS rather than via the library server.. or am I missing something here??

Richard

[glynor]

Sorry... I must have seen that thread (the one referenced repeatedly above) and then remembered incorrectly that this had already been done.  Once this change has been made, the Library Server may be useful for me, but until then I can't use it at all.

However, because of this... It also stinks that Tremote only works through the Library Server.  What if I want the library served by the server in the office, but I want the Tremote to control the HTPC (obviously)?  I'll post on this separately though.

[MrHaugen]

However, because of this... It also stinks that Tremote only works through the Library Server.  What if I want the library served by the server in the office, but I want the Tremote to control the HTPC (obviously)?  I'll post on this separately though.

Darn. I hoped the Tremote would work on every client This will be a setback for my plans as well.

[park]

Glynor, how did you get mkvs to play back through library server? I and a couple of others have been getting directshow errors whenever I hit play. Loading the shared library plays back the files fine for me though.

[glynor]

I also got the directshow errors occasionally, but they would sometimes work on the second try (after waiting the seemingly interminable period).  One thing that might be different for my setup is that I'm now using CoreAVC for video decoding of most MPEG-4 streams (including x264 and XviD).

The directshow errors seemed to be specific to the "larger" files, for some reason...

[Yaobing]

The directshow errors seemed to be specific to the "larger" files, for some reason...

It appears to be a "feature" of Haali Media Splitter filter.  The filter can load streaming files that are small, but not the larger ones.  Once loaded, it plays the file as stream without the ability to seek.

I changed my code a bit so Microsoft's "File Source (Netshow url)" is used to open streaming mkv file, as we already do for mp4 and a few other types. 

The change will not solve any of the problems glynor reported.  As far as I can tell, "File Source (Netshow url)" always downloads the entire file before playing, thus the huge delay.  The good news, if it can be considered as such, is that once downloaded, it will play fine, including seeking, because it essentially plays off a temporary local file.

AVI files are handled differently...

Alex also raised a good idea: making the client not use the server at all for cases where it can resolve the filename because it's UNC or a network share.  We're going to think about this one.

Do you think having a matching full file path on the local machine sufficient reason to believe a local file is indeed the same file on the server that one wants to play?

[glynor]

Do you think having a matching full file path on the local machine sufficient reason to believe a local file is indeed the same file on the server that one wants to play?

I'd say absolutely yes.  If the full path matches and is valid (meaning, including the exact file name and directory structure) then I'd call that every reason to think you've got local access.

[MrHaugen]

I'd say absolutely yes.  If the full path matches and is valid (meaning, including the exact file name and directory structure) then I'd call that every reason to think you've got local access.

Me too. It would at the very least be much less trouble from this than todays problem with the video delay. If we could mount the shared video directory as for instance M:\Video\ on server and the local machine and check for a local copy, this could probably be fixed with very little effort to the code? About the same with UNC paths I guess. Check if the UNC path is available from the client and use the direct path from the client.

Sounds to me like a quick fix for a rather big problem. This and the write limitations from several clients is the only two things that prevents me from using library server and more HTPC clients.

[jmone]

Mmmmm there must be another technical approach (UPnP / DLNA / ?) to this issue as other streamers don't have the problem with having to copy the file first before commencing playback.  Eg - TVersity or PS3 Media Server (http://code.google.com/p/ps3mediaserver/) supports both streaming and transcode/streaming (what I really want in MC) and they do have a startup pause it is nothing like what Glynor is reporting (and this is on GB sized files).

Thanks
Nathan

[Yaobing]

Mmmmm there must be another technical approach (UPnP / DLNA / ?)

Until we find a more elegant solution...

For now I added this DirectShow Video playback option - "Play local file if one that matches Library Server file is found".

[ThoBar]

Until we find a more elegant solution...

For now I added this DirectShow Video playback option - "Play local file if one that matches Library Server file is found".

Nice, thankyou!

[)p(]

Thanks...I think this is a good solution...changes that you get to different files with the same name should in normal use be negligible. And in the rare case it does occur it will be pretty obvious.

peter

[MrHaugen]

For now I added this DirectShow Video playback option - "Play local file if one that matches Library Server file is found".

Thanks! Finally I can start using the server functions
Does it check for local paths only, or does it also check UNC paths? You can map a drive on Server and the client off course, but it will take a little more time and effort to set up.

[glynor]

Until we find a more elegant solution...

For now I added this DirectShow Video playback option - "Play local file if one that matches Library Server file is found".

Hmmm... I really think that this should be the default behavior (if not even completely non-optional).  I'm trying to think about it...  Under what circumstances would you have an exact-matching full file path, and not want to use the local copy rather than a streamed one?  The only thing I can come up with is if you maybe had some temporary "junk-named" files (like M:\temp\temp1.avi and whatnot) and then ALSO had those same exact filenames, but different files, on the client machine.

One would think this would be exceedingly rare.  However, the normal case would be far more common.  If the library says a file is at "M:\Video\TV\Lost\4\4e07 - Ji Yeon.mkv" and there actually IS a file there, named that exact thing... Well, then obviously that's the one you want to play.

[MrHaugen]

I agree again. J River and the forum users would be saved from some questions if this behaviour was the normal one. And what if people don't ask how to fix this, and stops using MC because "it cant be used as a server for videos"?

If they have the files shared, and both server and client can access it, everyone will be happy, and no questions will be asked. Probably.

[Matt]

As an interesting data point, Media Center's Library Server is ofter faster than simple file sharing over the network.  I was surprised by this, but we did quite a bit of testing the other day.  The server is able to saturate a gigabit network without using too much CPU on the server.

There's still a problem of some DirectShow filters behaving badly with remote files.  We're thinking about whether we could help this by creating our own source filter.

[ThoBar]

As an interesting data point, Media Center's Library Server is ofter faster than simple file sharing over the network.  I was surprised by this, but we did quite a bit of testing the other day.  The server is able to saturate a gigabit network without using too much CPU on the server.

There's still a problem of some DirectShow filters behaving badly with remote files.  We're thinking about whether we could help this by creating our own source filter.

*Watching this space*

[glynor]

As an interesting data point, Media Center's Library Server is ofter faster than simple file sharing over the network.  I was surprised by this, but we did quite a bit of testing the other day.  The server is able to saturate a gigabit network without using too much CPU on the server.

There's still a problem of some DirectShow filters behaving badly with remote files.  We're thinking about whether we could help this by creating our own source filter.

Quite interesting.

(I don't think many people would shed a tear to see Haali's splitter go, and I assume that's what you're talking about here.)

[jmone]

I agree that a "better" filter is needed as:
1) MS Filter is very restrictive and what Audio streams it will generate a Pin Out on (eg I can not get a Audio Pin out if the Audio Stream is DTS in a mpg container)
2) Haali's splitter seems to be very touchy
3) Nero Splitter is my fav as it supports all Audio formats, is rock solid but does not support some containers and video streams.

The "ideal" splitter would work with all containers (MPG, AVI, (m2)TS, MKV etc), and support all pin outs to connect to decoders for all major Video (MPEG2, DV, MPEG4, AVC etc), Audio (PCM, DTS, DD, Lossless versions etc), as well as Chapters and Subs.

Good Luck!
Thanks
Nathan

[hit_ny]

As an interesting data point, Media Center's Library Server is ofter faster than simple file sharing over the network.  I was surprised by this, but we did quite a bit of testing the other day.  The server is able to saturate a gigabit network without using too much CPU on the server.

Not sure why there should be much CPU load on the server during a file transfer to begin with. If i'm not mistaken isn't it the client that does the decoding ?

There's still a problem of some DirectShow filters behaving badly with remote files.  We're thinking about whether we could help this by creating our own source filter.

Does each format require its own filter or can they all be made to use just the one.

[glynor]

Not sure why there should be much CPU load on the server during a file transfer to begin with. If i'm not mistaken isn't it the client that does the decoding ?

Network access and disk access both entail CPU load, sometimes substantial, especially with typical commodity hardware and drivers.

[park]

There's still a problem of some DirectShow filters behaving badly with remote files.  We're thinking about whether we could help this by creating our own source filter.

Sounds very promising.

With sidecar files for video tagging, read write access to the library from any machine anywhere, and an MC splitter that would simplify media playback for newbies, I think you'll have the most compelling update for several versions. Image preview is developing nicely too.

[jacky]

thanks glynor for writing this thread, saved me from having to write it.

Also, further testing will find that ripping CDs is impossible with this method.

I too have a RAID5 server with DVDs rips, Videos connected to several HTPCs on a 1Gb network, and find the current implementation of Library Server to be useless.

[jacky]

I would prefer a LAN mode of this Library Server, implemented so that while the library database is accessed from the server, the files are accessed DIRECTLY using network paths (ie:\\server\movies\dvd1\videots\video.vob)

This would minimize complexity and the work Library Server has to do.

Any thoughts?

[MrHaugen]

Until we find a more elegant solution...

For now I added this DirectShow Video playback option - "Play local file if one that matches Library Server file is found".

I believe this is what Yaboing made possible Jacky. Try the new DirectShow Video Playback option.

[jacky]

Thanks for pointing that out.  I missed that post on this long thread. 

So how does it know where to look locally for these files?
Do I have to add the local folders to the Auto Import for it to know where to look?

[greybone]

Wow, is there any issue with media center I won't find out is fixed already?

This is great! Thanks!