UPnP / DLNA Media Server for MediaPortal 2 (3 Viewers)

[henso]

My planned changes are:
remove <UPNPDeviceDescription>
replace <Detections> with <Targets>

Here is my first port of the profiles. I opted for keeping <Detections>. Why have a different name for the same thing? The detection objects is something I put in. I don't know if they work correctly.

 

[FreakyJ]

Thank you very much for porting

Why have a different name for the same thing?

It is actually different:

<Targets>
      <Target>
        android
      </Target>
    </Targets>

MPExtended uses this to determine which client gets which profiles. You can request the Profiles by handing a "target" to MPExtended. Sure you can also retrieve android profiles e.g. for a webservice, but this is up to the developer if this makes sense.
By renaming this we don't get conflicts in case one just copies a profile from the DLNA Server to MP2Extended, because it gets just ignored.

Does that make sense? If not I am happy to change

 

[henso]

MPExtended uses this to determine which client gets which profiles.

OK, now I understand. I was actually also thinking about having some kind of filter option so this serves the same purpose. I'ts fine by me if you edit the profiles.

 

[FreakyJ]

I've fixed two issues.
Our FFMpeg Version doesn't support libfdk_aac and the short path didn't work for me

We also should think about an option to start the transcoding in the middle of a file. Maybe by using this: http://stackoverflow.com/questions/28476190/ffmpeg-partial-transcode-using-ss-and-to

 

[henso]

short path didn't work for me

Yeah, I don't even remember why I used it anymore. Shouldn't we just remove it if doesn't work on all systems anyway?

transcoding in the middle of a file.

My initial idea was that transcoded files could be cached for by others requesting the same file.
I would have to rethink the cache strategy for this, but I think it is necessary too.

 

[FreakyJ]

Yeah, I don't even remember why I used it anymore. Shouldn't we just remove it if doesn't work on all systems anyway?

hehe, okay^^ I thought you had a reason for adding it. I just removed it.

My initial idea was that transcoded files could be cached for by others requesting the same file.
I would have to rethink the cache strategy for this, but I think it is necessary too.

Yes, caching is a good idea and I see the problem if the transcoding starts right in the middle. Maybe we should only cache if we started transcoding from the beginning, otherwise we should just transcode on the fly.
But maybe you have a better idea. Would be great!

 

[henso]

But maybe you have a better idea.

I think I have but let me think about it first.
I will look into it next week. I'm going away for the weekend.

 

[MrTechno]

@FreakyJ I've started porting the DLNA plugin to the MIA rework branch. Doesn't compile yet, progress report to follow.

 

[FreakyJ]

I am fixing the HLS Streaming in the Transcoding Plugin right now (basically just adjusting some paths so that it doesn't output into the MP2-Server Application dir).

For getting the playlist file we use:

Stream stream = new FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

The problem is that FFMPEG doesn't like this and creates another file, if we don't open teh file ffmpeg doesn't do that. Has anyone a clue what could be wrong? Or how I could figure out what is wrong?
The options above indicate that it shouldn't be a problem for ffmpeg to write to this file...

 

[FreakyJ]

I hope I solved the problem after a long night I was reading the FFMpeg src for hls: http://ftp2.halpanet.org/source/_dev/ffmpeg.git/libavformat/hlsenc.c
It looks like FFMPeg create a tmp file with the newly created segment files and than replaces the playlist file with the tmp file. It does this for every new segment.

Now the problem: Our TranscodingService opened the file, but never closed it. This lead to the fact that FFMpeg couldn't replace the playlist file. I now close it after reading and reopen it:

if (resourceStream is FileStream)
        {
          ServiceRegistration.Get<ILogger>().Debug("Is FileStream");
          if (!((FileStream)resourceStream).CanRead)
            resourceStream = new FileStream(((FileStream)resourceStream).Name, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
        }

I don't know if this is a really elegant solution, but it looks like it is working and I will provide a patch for our TranscodingService