Print

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

[Trumpetguy]

Ok, this is becoming a major thing in our family's media daily life, and it bugs me that I cannot figure out a good solution. I have been unable to search the forum for good solutions, and the wiki haven't helped.

All video is stored in my HTPC (Win7) in the basement, running Media Server (MC19). In the living room I have a laptop with a local MC19 installation connected the the HTPC library through my LAN. I also have my work laptop connected externally to this network when on travel, sometimes watching the odd movie. The videos are stored either as mt2s rips, mkvs, divx files or vobs. I have tested several client pcs running MC19 on WinXP, Win7 and now Win 8.1 (I will not go into how close W8.1 is to be set on publicly fire in our town square while throwing bad thoughts to MS, but that is not relevant for this post). All MS versions show the same behaviour, and I do not think win version relevant. This behaviour is also the same on Gizmo.

For all file types I am able to start playback, but it is only possible to play continously from start to end  (pause works). Skip or seek is not possible, which is a major hassle for the kids when returning to watch the rest of the movie they left half seen the day before. In practice, this is a show stopper for using media network for video.

The second thing is that I haven't figured out how (or if) it is possible to choose audio track on the client pc. The only audio track available is the first one. This is also a setback for my non English speaking kids, as the Norwegian audio rarely is track number 1. The only workaround I have found is to create MKVs (maybe other containers also) forcing the Norwegian overdub as audio track 1.

Could anyone answer how to solve this? Please...

[Arindelle]

Ouch. What a drag.

The only thing I can think of would be that your clients may not be configured properly?  Assuming that all "client" pcs for your kids also use PCs with MC installed (not all UPNP devices work well).  I find that the JR network password is better than the IP address route. Make sure that each client is using this protocol and is not pure DLNA. I would also verify that all clients are loading the main library from the basement PC through mapped drive(s). Also that each client is not running media server.  But you probably have done all that^^

Can't think it would be with the basement media server PC or they wouldn't have acess at all to the files. OK you can have lag on your network and other irritations but its really not at all what you are describing.

As for the subtitles, I don't have any so can't help at all.

My mother was Norwegian from a town called Risor ... I'm American living in France ... go figure

good luck on this

[Trumpetguy]

Never thought of that solution - mapping disks from the basement computer and creating a local library in the living room pc. A lot more work, since the views need to be built from scratch on this computer. And I am almost allergic to duplicating anything, especially when we are working with databases. But at least it works. Not too happy about it, though. All this focus on media networks, and it cannot be used. Not good.

I would really like this problem to be on the todo list!

[Trumpetguy]

The main problem with using a local library and video files on the LAN (mapped drives or Homegroup drives) is transfer capacity over WIFI. One of the key things about Media Network is the ability to do real time transcoding to something that fits your streaming capabilities.

Now, using local library in the living room gives me full functionality, but most movies stutter violently if starting at all.

Back to square one.

Are there really no one else struggling with this?

[Arindelle]

Never thought of that solution - mapping disks from the basement computer and creating a local library in the living room PC. 

I am not sure you understood me (or vice versa?). You certainly don't want to create duplicate libraries. Especially if you are stocking all your media in one place and sharing it.  If you have dlna only devices, well you have to go that route, which will have reduced functionalities depending on the renderers. If not which seems to be your case, run Media server in the basement and all other PCs run just as clients and load the basements libraries (all machines will have a library marked "local" btw)

I've got to run .. will get back to you later on this

[Trumpetguy]

Appreciate you helping out here!

Make sure that each client is using this protocol and is not pure DLNA.

The clients are linked to the server using a networ key and password. All files are accessible, and playback is always smotth and stable (for video when it is transcoded realtime because of bandwidth). What makes me confused is this paragraph:

I would also verify that all clients are loading the main library from the basement PC through mapped drive(s).

Could you please explain what you mean by "through mapped drive(s)"? The clients are loading the main basement library, and all files on the basement pc are stored on internal hard drives on that computer. No NAS, external USB disks or anything.

My mother was Norwegian from a town called Risor ... I'm American living in France ... go figure

Ooohh, Risør - nice place in south Norway. Some 800km south of where I live (Trondheim). Fun fact: Norway is a small country, but some 2500km north-south, almost as long north/south as the rest of Europe.

[Trumpetguy]

*bump*

I find it hard to believe that no one else are troubled by the lack of skip and seek through media network!

I have started investgating other possibilities, like Plex... even if I don't want to.

[Trumpetguy]

Now I get a variety of in part non-reproducible symptoms:

dvds ripped to m4v/mp4 makes MC use 100% wifi capacity and just locks up.

With ROHQ, some movies (sometimes, not always) makes screen go all green, and progress bar is filling up to 100% or acting weird.

For some movies, skip and seek actually works (some of the mkvs and ripped bdmvs).

For almost all files, doing online video conversion is not working, they play back at full bitrate and quality whatever conversion is set. For a few movies, conversion is working, but then progress bar is lost again.

This is weird.

[hcshrader]

I have the same problem and it is driving me crazy. Pause works, but when I try to fast forward, it does, but when you press play, it starts at the beginning of the video. I fixed this the first time I got it by unckecking the network synch box in the Options/Media Network space.

Then, 2 months later it reappears and I fix again.

Now it has come back but I can't seems to fix. No amount of tampering with DNLA roles or media network preferences seems to have an effect. I do restart the computer and the WD LIVE TV unit, but to no avail...

Help JRiver- how should WDLIVE TV be configured within  JRiver?

[Trumpetguy]

There is a number of other symptoms that may be to any help (to me it is just confusing):

Gizmo on my HTC droid works fine for all the movies I have problems with on the computer MC network client, except mp4/m4v files. For these, there is an error message saying something like "Communication error with server". All movies play just fine locally on the computer running the server, be it mp4/m4v, bdmv vob or mkv.

On two different network (laptop) clients in the same home network, I get two different results. They both run 19.067. It will take me a full night to try an systematically describe the symptoms and differences, but here are some:

New laptop: No difference in bitrate regardless of client video conversion (alomost, some downscaling to MPEG2/DVD sometimes work, but then time info is lost)
Old laptop: Responds to some video conversion types, more than the new one. Timing info is then always lost.

My thinking is that as long as Gizmo can do online conversion and responds to skip, this should work on computer clients as well.

[Trumpetguy]

Ok, so I'm progressing somewhat  

Network video playback works (with progress bar and skip/seek) under the following conditions:
- playing from Theater View on the client (not Standard View, and this is weird so I'm going to test further), AND
- there is no video conversion on the client, AND
- the movie IS NOT BDMV rip from BluRay disk (ripped to MKV works).

[Hendrik]

Seeking not working when video conversion is active is a known limitation right now. I hope to address it at some point, but no promises on a time frame yet.
BDMV playback is in the same boat. You can get it to work if you map the storage of your movies under the same path on your clients - but of course that only works on local network.

[AndrewFG]

Seeking not working when video conversion is active is a known limitation right now. I hope to address it at some point, but no promises on a time frame yet.

Hendrik, the following are just a few technical tips based on my own experience:

For a network renderer client to do a Seek, it must send an HTTP GET containing a "Range: bytes=9999-" header (where 9999 represents the byte offset), so the client needs to convert a seek target time (in seconds) to a byte offset (in bytes), and therefore it needs to know two out of three of the following attributes:

• the Content-Length header value (in bytes), which must be provided by the HTTP server
• the track duration (in time), which must be provided in the meta data either via UPnP SetAvTransportURI (push), or via UPnP Browse (pull)
• the bit rate (in bytes per second), which must be provided by ... ditto ...

So you need to be sure to provide accurate values in the Content-Length header and the meta data values...

Furthermore, it is best for both server and client if the Range: bytes request exactly aligns with the start of a data frame (audio or video) -- otherwise you may get a burst of noise before the renderer can lock on to the next frame. Now if you are streaming something with a fixed frame size e.g. uncompressed PCM audio (frame size = bit depth x channels x sample rate) then it is very easy for the Range: bytes frame alignment to be done (so long as you provide the correct values in the HTTP Content-Type header). Whereas if you are streaming anything with a variable frame size (almost any other audio, video format than PCM) then it is exceedingly hard to align the frames. And in this case, it is probably better if the server starts sending a "clean" stream, without trying to double guess the frame alignment behind the Range: bytes request.

Edit: and once you have implemented Seek in MC, it must supply an Accept-Ranges header to indicate to the client that it can support Seek on that url.

[Hendrik]

MC doesn't use UPnP/DLNA for playing from its own Media Server, so it can simply seek based on a timestamp like Gizmo. It just doesn't do it yet.

[Trumpetguy]

Seeking not working when video conversion is active is a known limitation right now. I hope to address it at some point, but no promises on a time frame yet.
BDMV playback is in the same boat. You can get it to work if you map the storage of your movies under the same path on your clients - but of course that only works on local network.

Thanks, that was the best and most precise explanation I have got on this topic. A bit disappointed, though. It will take some convincing to make me believe that this is not a problem for quite a number of users.

In the meantime, my MKVs need to stream on a 25+ Mbps, to our living room. This could be 6 Mpbs with video conversion active... But hey, that means I will need to install that CAT5/6 cabled network.

[bob]

Decent renderers support time based seeking which we already support.

[Trumpetguy]

Bob, I don't think I got the message in your statement, please explain.

What I think you are writing is: 'MC has decent renderers, and has the technical means to support time based seeking. And JRiver ambition is to make it work, also with video conversion activated.'. ?   

[Hendrik]

I think he was mostly responding to AndrewFG above, who mentioned all these things about byte-based seeking.

But he confirmed what i basically said earlier, MC already has all the tools required, they just dont come all together yet to make this work. But we'll make sure it does in the future.

[Trumpetguy]

I think he was mostly responding to AndrewFG above, who mentioned all these things about byte-based seeking.

But he confirmed what i basically said earlier, MC already has all the tools required, they just dont come all together yet to make this work. But we'll make sure it does in the future.

Ok, thanks.

[Hendrik]

In case you are still waiting for this, I just wanted to let you know that seeking when video conversion is active will be supported in one the next builds of MC19.

[Trumpetguy]

That is truly excellent news! And yes, I am still waiting for this 

About my other question in the OP - would it also be made possible to choose audio track?

[bspachman]

Wow! Best news I've had in a while! I'm just bumping into this problem with the acquisition of 2 new DLNA renderers (read: smart TVs) in the house. I thought I was going batty, and finally decided to search a bit to see if it was a known configuration problem!

I'll cross my fingers to see if an upcoming build helps....

brad

[bob]

In case you are still waiting for this, I just wanted to let you know that seeking when video conversion is active will be supported in one the next builds of MC19.

I guess I need to clarify what I was referring to in my too short comment. I was only talking about the case of MC serving content to a hardware player (DMP) or renderer (DMR).

case: MC is serving content via DLNA to a renderer to a  player pulling the content (like a PS3).
In this scenario if the renderer supports time based seeking then pause, seek, etc already work and have been for over a year.
When I said DECENT renderers support time based seeks I meant the better quality renderers I've seen support time based seeking.
I'm fairly certain this should work pushing from MC to a DMR too IF the DMR supports time based seeks.

Now there are a LOT of renderers that do not support time based seeking. These will not seek and generally will not pause (though some will by stalling).
Since they use byte based seeks and we can't give the renderer the size of the file while it's converting they won't try to seek (there are some renderers that work around this by reading and discarding content).
We can give the renderer a phony content length, say some number we know will be larger than the final file, however in some of these cases, the renderer if it thinks it has a file length will try to seek to the end and fail so this is not a great solution.

Everything above refers to streaming conversions.

For files not being converted, since we know the content length and it's just a file, byte based seeks are fully supported and all of the pause, seek, etc works as expected. Since we have a file we don't support time based seeks in this scenario.

Hopefully this clarifies the situation.

[jmone]

Great work! 

[Hendrik]

Wow! Best news I've had in a while! I'm just bumping into this problem with the acquisition of 2 new DLNA renderers (read: smart TVs) in the house. I thought I was going batty, and finally decided to search a bit to see if it was a known configuration problem!

Sorry, but the only thing this fixes is streaming from MC to MC with video conversion (Trumpetguy's use-case)
It won't help with DLNA at this point.

[AndrewFG]

Now there are a LOT of renderers that do not support time based seeking. These will not seek and generally will not pause (though some will by stalling).
Since they use byte based seeks and we can't give the renderer the size of the file while it's converting they won't try to seek (there are some renderers that work around this by reading and discarding content).
We can give the renderer a phony content length, say some number we know will be larger than the final file, however in some of these cases, the renderer if it thinks it has a file length will try to seek to the end and fail so this is not a great solution.

IMHO this is a very strong argument to encourage you to stream in non compressed lossless formats only (in the case of audio this would be LPCM, WAV or AIF). The reason is that your "phony content length" can be calculated with a very high degree of accuracy from knowledge of the time duration, the sample rate, channel width and bit depth.

In Whitebear I calculate the phony content length using the file duration less about 100..200 milli seconds so that if the renderer does a GET for the end of the stream, there is still some material available to be delivered. In my experience this seems to avoid stalling the renderer. (Perhaps another way would be to deliver audio silence samples for any GET that accidentally overruns the physical material duration -- up to a limit of say 1..2 seconds).

The formats where it is more problematic to supply a phony content length are the compressed lossy, or compressed lossless formats such as MP3 or FLAC. In my case in Whitebear, I deliver those formats by transcoding them on the fly to a format where the phony content length is actually predictable. So in the case of MP3 I transcode up to a Constant Bitrate Rate of 320kbps, and in the case of FLAC I transcode to an uncompressed FLAC stream with all the FLAC compression algorithms turned off (this results in a FLAC whose size is calculable, and which is slightly longer than the equivalent LPCM, WAV or AIF stream -- but who cares...).

Obviously if you are delivering a native file, then you know the physical content length, and can deliver that value as is.

[Hendrik]

IMHO this is a very strong argument to encourage you to stream in non compressed lossless formats only (in the case of audio this would be LPCM, WAV or AIF). The reason is that your "phony content length" can be calculated with a very high degree of accuracy from knowledge of the time duration, the sample rate, channel width and bit depth.

Audio is easy, and MC can already serve PCM to DLNA devices, streaming uncompressed video is where you get into trouble.
Of course we could try to stream a strict CBR video stream, calculations may not be 100% accurate, but maybe 99%. I should test my TV, wonder what it supports..

[Trumpetguy]

IMHO this is a very strong argument to encourage you to stream in non compressed lossless formats only (in the case of audio this would be LPCM, WAV or AIF). The reason is that your "phony content length" can be calculated with a very high degree of accuracy from knowledge of the time duration, the sample rate, channel width and bit depth.

....
Obviously if you are delivering a native file, then you know the physical content length, and can deliver that value as is.

I assume you are only thinking audio streaming here?

Seen from this user's point of view this will render MC as useless for video streaming to MC clients on external networks. Even inside the house uncompressed video will be difficult in most rooms when connected to wifi LAN. A bluray easily needs >25Mbps. Even if my server is at the end of a 30 Mbps fiber, my laptop with the MC client is often on a hotel wifi with 1-2 Mbps capacity.

[AndrewFG]

I assume you are only thinking audio streaming here?

Audio is easy, and MC can already serve PCM to DLNA devices, streaming uncompressed video is where you get into trouble.
Of course we could try to stream a strict CBR video stream, calculations may not be 100% accurate, but maybe 99%. I should test my TV, wonder what it supports..

As you both say, audio is easier to do lossless for bandwidth reasons. But you can also do this trick for lossy media so long as you use a constant bit rate format.

So for video, I would indeed support Hendrik's suggestion to go for a strict CBR stream. As I mentioned above, in Whitebear I offer a "phony content length" (bytes) := ((track duration from the tags) - (100..200 milliseconds)) x CBR / 8 and this seems to work on most audio renderers.

Note that you must also supply an Accept-Ranges header so that the renderer knows you can support byte seek operations.

{ And by the way, when you do get a byte seek range request, (especially a byte seek on a lossy stream), I advise that you keep in mind the risk that the renderer might mistakenly request data starting at a byte offset that falls part way through a frame (leading to synching errors). Renderers ought to only seek at frame boundaries, but they might sometimes get confused. For this reason in Whitebear when transcoding to a CBR lossy stream, when I get a byte seek range request, I stop the current transcoder and start a completely fresh CBR transcoder stream that starts at the time offset that corresponds to the requested byte offset divided by the CBR ... but also continuing to offer the original phony content length value and the corresponding values in the content range header. The programming of this stuff is a coder's "delight" ... }

[Trumpetguy]

So for video, I would indeed support Hendrik's suggestion to go for a strict CBR stream. As I mentioned above, in Whitebear I offer a "phony content length" (bytes) := ((track duration from the tags) - (100..200 milliseconds)) x CBR / 8 and this seems to work on most audio renderers.

Excuse my ignorance, could you explain what Whitebear is? Is it this: http://www.whitebear.ch/mediaserver? Interesting product, new to me but shall be investigated if it has its place together with my Squeezbox classic.

[bob]

Audio is easy, and MC can already serve PCM to DLNA devices, streaming uncompressed video is where you get into trouble.
Of course we could try to stream a strict CBR video stream, calculations may not be 100% accurate, but maybe 99%. I should test my TV, wonder what it supports..

And since we transcode audio to mp3 CBR and provide a content-length, you can stream those conversions fully seekable as well (it's been that way for years).
Video is the issue here.
And streaming video CBR doesn't solve the problem of some braindead renderers seeking to the end of the file for no particular reason because you tell it where the end is.
This completely egregious behavior is what we found on some of the android phones (the note 1 was the first we ran into) when we tried to stream video to them over Gizmo.
It must have something to do with the flavor the vendor put on the phone because it doesn't seem to matter what version of android from the vendor is running you get the same behavior but when you switch to cyanogen, viola it works. It seems to me that the vendor is trying to prevent streaming from apps not under it's control.

[AndrewFG]

And streaming video CBR doesn't solve the problem of some braindead renderers seeking to the end of the file for no particular reason because you tell it where the end is.
This completely egregious behavior is what we found on some of the android phones (the note 1 was the first we ran into) when we tried to stream video to them over Gizmo.
It must have something to do with the flavor the vendor put on the phone because it doesn't seem to matter what version of android from the vendor is running you get the same behavior but when you switch to cyanogen, viola it works. It seems to me that the vendor is trying to prevent streaming from apps not under it's control.

Hi bob,

Brain dead on one hand...  and trying to be too smart on the other...  definitely not a good mix  

But seriously though. I have seen such renderers too on the audio side. First they do a GET at the start of the stream. Then they do a GET at the end of the stream. And then finally they do the real GET to download the stream. I think that the motivation of the first GET is to 1) establish that the stream is servable, and 2) to establish the mime type, content length, and accept range capabilities from the headers. And I think that the motivation of the second GET is to 3) establish that the stream is more or less as long as it was originally claimed to be in 2), and 4) prove that byte range seeks are indeed possible, and 5) (possibly) pull in any existing ID3 tags (or DRM stuff) attached to the end of the file. Then (obviously) the motivation of the third GET is to -- well -- get the actual stream...

Notwithstanding the above, I don't really understand why so many renderers follow this odd behaviour, but I suppose it is because somebody once published a library that does this, and none of the renderer manufacturers can be bothered, (nor have any know how), to do anything different than what that original somebody wrote in their library...

But in any case, from my experience, if your are a server, (which you are), the most important thing is for you to ensure that neither the first GET nor the second GET shall fail. This means these calls must return a 200 OK success code, and valid and appropriate HTTP headers. Then -- so long as you have passed those first two tests -- the third GET will be started to actually do the real business of downloading of the actual media stream content. And if you passed the first two tests, this third GET will normally succeed without too much hassle, and also any subsequent byte range GETs (within the content length) will probably also succeed without much hassle.

This is therefore the reason why Whitebear returns a phony content length slightly less than the actual calculated value -- just to make sure that the second GET can indeed succeed.

{ PS it is also my experience that on the first GET and on the second GET, the renderer usually kills the socket after the first few IP frames have been delivered (after around 10k bytes or so). Which confirms that both these two gets are basically more interested in the headers than in the contents. I won't say that you can get away with delivering garbage, but I think that returning audio / video silence would also be Ok }

[AndrewFG]

Excuse my ignorance, could you explain what Whitebear is? Is it this: http://www.whitebear.ch/mediaserver? Interesting product, new to me but shall be investigated if it has its place together with my Squeezbox classic.

Yes. The link explains the details better than I could do it here...

[Trumpetguy]

Yes. The link explains the details better than I could do it here...

Right, and now I also noticed your signature 

[Trumpetguy]

Yes! in the last Gizmo build (and combined with 19.108 i guess) skip and seek worked     
Just tried it briefly on a low capacity, unstable network, at it still worked pretty well.

Thanks a lot for this incredible improvement!

[Trumpetguy]

An old thread brought to life. After working for a long time,  skip has stopped working both on media client, gizmo and now also eos, the new Android remote. When trying to tap on the progress bar to skip, it always starts at the beginning again.

[bob]

An old thread brought to life. After working for a long time,  skip has stopped working both on media client, gizmo and now also eos, the new Android remote. When trying to tap on the progress bar to skip, it always starts at the beginning again.

What is your build number? Which update channel are you on?
I assume it's just the most recent build?

[Hendrik]

There was a bug in one singular build a bit ago that caused this, but that should be resolved in latest.

Specifically it was broken in 143 and 144, fixed in 145 and above.

[Trumpetguy]

What is your build number? Which update channel are you on?
I assume it's just the most recent build?

19.0.149
I usually install latest build quite promptly, is that what you mean by 'update channel'?

[6233638]

19.0.149
I usually install latest build quite promptly, is that what you mean by 'update channel'?

Help → Update Channels in the menus lets you select the channel Media Center checks for auto-updates. (Stable/Latest/Beta)

[Trumpetguy]

Help → Update Channels in the menus lets you select the channel Media Center checks for auto-updates. (Stable/Latest/Beta)

Ok :-) it is always set to Latest. Usually that's fine, but should I rather try a 'Stable' this time? Hendrik mentioned something broken in some quite recent builds that had been fixed, so I thought using the latest would be best.

[Matt]

Ok :-) it is always set to Latest. Usually that's fine, but should I rather try a 'Stable' this time? Hendrik mentioned something broken in some quite recent builds that had been fixed, so I thought using the latest would be best.

It's up to you.  Latest gets newer and more builds but has a greater chance of problems.

[Trumpetguy]

It's up to you.  Latest gets newer and more builds but has a greater chance of problems.

I know, but I have never experienced this.

Now back to my problem - can this be related to the (potential?) issue with Xperia Z1? Now, I have a Z2, but is see the same behaviour as discussed here: http://yabb.jriver.com/interact/index.php?topic=87340.0 I have tried HTTP Live streaming and that does not work at all. Without this option, it seems that video is streaming, and for some movies it does. But skipping to another location in that movie makes Gizmo either crash (with an error message stating that Gizmo has stopped working) or simply go back to the menu.