Print

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

[jkauff]

When playing a movie on my TV via DLNA/Media Server, clicking Pause then Play does not resume playback, it restarts the movie. Seek does the same thing. I can move the Seek bar, but when I release it the movie starts from the beginning.

This happens both on MC20 and JRemote. Is this a limitation of DLNA, or something the devs could fix? I could live without Seek, but I always use Pause when playing a movie.

By the way, Pause/Play and Seek work perfectly playing an audio file.

[AndrewFG]

The Pause and Seek issues are caused by the same thing.

The issue is known to JRiver, but it is quite difficult to solve, and so has not been a top priority for them.

To solve it requires the following things:

- the MC server must supply an Http ContentLength header
- the MC server must supply an Http AcceptRanges header
- the MC server must provide DIDL with at least two out of the following three attributes: duration, size, bitrate
- the MC server must honour Http Get requests having RangeBytes entries, with a 206 partial content response, plus a ContentRange value

In order for the MC server to be able to do these things, it needs the following capabilities:

- ability to estimate the ContentLength of a transcoded stream
- ability to translate a RangeBytes offset into a time offset into the transcoded stream
- ability to initiate a new transcode session starting from said time offset

It would also help MC (but is not a must) if it were able to do the following:

- ability to cache / buffer a full or partial stream transcode to disk, so that if a RangeBytes request comes in within the already transcoded disk image, it gets served from cache, and only starts a new time offset transcode if the Range request is out of scope of the disk cache

Note: the above is what I do with my own Whitebear server code, so I know that it works...

[Hendrik]

We support time-based seeking (using "TimeSeekRange.dlna.org"). Byte-based seeking is extremely clunky with on-the-fly transcoding into a modern codec like H.264, since you would not want a fixed constant bitrate for efficiency reasons, so I wouldn't hold my breath for it.
Its possible that we may work on it eventually, but there certainly are no immediate plans for it.

So in short, get your DLNA device to issue time seeks.

[AndrewFG]

Hendrik, my point is that if you can already do time based seek then it is actually a trivial matter to do byte based seek as well; you just convert the byte offset into an equivalent time offset, and serve that; you don't need to force CBR to convert the byte offset to time offset; just using an average bit rate is accurate enough so long as the seek ends up within +/- 5 seconds or so of the proper target..

PS in fact ANY seek offset (even if the seek target is very innaccurate indeed) is anyway far far better than your current "solution" where it defaults to restarting at the beggining of the track.

[Hendrik]

You would think so, but no. With our encoding mode we cannot even begin to estimate a final file size as it is. We specify a maximum bandwidth, but the encoder is free to use less bits if it sees fit to do so, which can result in quite varying file sizes depending on content complexity.

Anyway like I said, it might be fixed eventually, but not now.

[AndrewFG]

Hendrik I added a footnote in my prior post.

You would think so, but no. With our encoding mode we cannot even begin to estimate a final file size as it is. We specify a maximum bandwidth, but the encoder is free to use less bits if it sees fit to do so.

Not only do I think that. But I KNOW it for a fact. Because I have done it myself..

PS there are usually switches on the transcoders to turn off advanced compression. This results in bigger files, but a more predictable overall file size. Having a smaller transcoded output is anyway irrelevant, since it is only bits over the LAN and Ethernet has enough bandwidth...

[Hendrik]

Our current solution is to recommend accurate time based seeks. Byte seeking is not in the cards right now, that's just where we stand.

[AndrewFG]

Again I added a footnote to my prior post..

Our current solution is to recommend accurate time based seeks. Byte seeking is not in the cards right now, that's just where we stand.

You are being very stubborn. You could easily improve the user experience for many users. Why are you being so dogmatic?

[Hendrik]

If we had infinite time we could fix everything, but we don't, so we have to pick and choose what we work on. Its as simple as that.

The entire transcoding engine is up for a redesign sometime this year, until that's done its not flexible enough to support any kinds of special behavior for DLNA anyway.

[AndrewFG]

Ok. I suggest you add byte based seek (byte seeks wrapped around time seeks) to your design architecture specifications. It reuses all your time seek code, and just adds

A)  (time seek offset) := (byte seek offset) X (estimated bit rate)
B)  (content length) := (duration) X (estimated bit rate)

And as you can see, the estimations often cancel out...

[jkauff]

Hendrik, I can understand how seek would be difficult with transcoding, but I don't use transcoding. I have a gigabit Ethernet connection to my TV, so bandwidth is no problem. Without transcoding, is it really that much different from using seek in an audio file?

As I said before, I can live without seek. Can you get Pause/Play to work without a lot of effort?

[Hendrik]

I don't know why it doesn't provide this information required for seeking when not transcoding. Bob could probably shine some light on that.

[daveman]

I have the same problem but only with hi def mkv files

dave

[bspachman]

I was having similar issues--primarily with mkv files, but also with mp4 files. My renderer (a Panasonic TV) supposedly was able to handle those filetypes 'natively.'

Turns out I had a lot of cruft in my DLNA server settings in MC from past experiments, and clearing out most of the settings to their defaults helped a great deal. In case they are useful to anyone else, what got both MKV and MP4 files working well (Play/Pause/Seek) are:

Code: [Select]

AUDIO--
     Mode: Specified output format only when necessary
     Format: MP3 high bandwidth
Audio Advanced--
     Stereo downmix = enabled
     Volume leveling = enabled
     Sample rate: Same as source
     DSP Studio = nothing enabled

IMAGES:
     Mode: JPEG (1080 TV)

VIDEO:
     Mode: Original
     Format: H264-TS very high bandwidth stream auto fps
Video Advanced:
     Enable: DLNA; DLNAExtra; Enable bitrate Field; Present Caption Resources;
               Present Small Artwork; Present Subtitle Resources
    Empty values for Video MimeType Override & Video DLNA Override


I remember the biggest key was clearing out old values in the two video override fields.

Hope this helps...

Brad

[daveman]

This worked great!

I am now able to fast forward and pause mkv files

That said, i still have more tests to do but I think this solved the problem.

Just so others know, this ff/rewind issue is much talked about in relation to the Western Digital Live.  I will let others know that JRiver overcomes the problems with these settings.

May be worth setting up a saved DLNA profile for WDTV

dave

[cyberhck]

The Pause and Seek issues are caused by the same thing.

The issue is known to JRiver, but it is quite difficult to solve, and so has not been a top priority for them.

To solve it requires the following things:

- the MC server must supply an Http ContentLength header
- the MC server must supply an Http AcceptRanges header
- the MC server must provide DIDL with at least two out of the following three attributes: duration, size, bitrate
- the MC server must honour Http Get requests having RangeBytes entries, with a 206 partial content response, plus a ContentRange value

In order for the MC server to be able to do these things, it needs the following capabilities:

- ability to estimate the ContentLength of a transcoded stream
- ability to translate a RangeBytes offset into a time offset into the transcoded stream
- ability to initiate a new transcode session starting from said time offset

It would also help MC (but is not a must) if it were able to do the following:

- ability to cache / buffer a full or partial stream transcode to disk, so that if a RangeBytes request comes in within the already transcoded disk image, it gets served from cache, and only starts a new time offset transcode if the Range request is out of scope of the disk cache

Note: the above is what I do with my own Whitebear server code, so I know that it works...

Hi there,
I'm trying to get DLNA to work on my videos, I'm using a npm module to do that, but the files that are hosted probably don't provide DIDL of things like you mentioned.

I could confirm they actually provide others, like content length, range and it also lets me request using bytes range.

But the DIDL part I didn't understand, say I'm writing a media server (or modifying an existing one), what's this DIDL thing, and how do I provide? Because when I looked at logs while playing the video, my TV didn't even request for DIDL, is that some first few bytes of video file or some headers thing? It'd be awesome if someone could help me out.


My issue is that when I use dlnacast2 npm module, it does play video but it can't seek, however from windows, right click and cast to tv, it can seek those files, my hunch is either it needs that DIDL, or the windows software is actually allowing time based seeking.

Where do I proceed? I'm currently using http-server to serve video files. I feel like I just need to change the way I host files.

[AndrewFG]

DIDL = Digital Item Declaration Language (Google is your friend). If you are writing a UPNP server then you need to study the specifications for Digital Media Server (ContentDirectory) and Digital Media Renderer (AVTransport) which you can find on UPNP.org.