[emveepee]

I"ve been able to confirm that EDL support works very well for the http streaming that NextPVR uses, but there are a few issues with how the baseline XBMC code works with http PVR backendd. Primarily the problem is that most of the code is not generic it is tuned to how specific addons identify reoordings with the custom URI pvr://recordings/filename.pvr

Before I create a pull with some changes to get this working I was looking for guidance on the proper approach to take

1) Simple - brute force.

when PVR manager is running send all http urls to the PVR client to see if it can load an EDL.

2) Modify the plugin to use pvr://recordings/*.pvr notation and modify CPVRFile::TranslatePVRFilename and PVRClients->GetStreamURL() to be more recordings aware

Suggestions welcome.

Martin

[opdenkamp]

you're going to have to do this based on the metadata that is available and not based on the (virtual) filename, and add methods for retrieving the edl to the pvr api.

[emveepee]

The problem with the existing code is Edl.cpp is based on URIUtils::IsPVRRecording(const CStdString& strFile) which is solely based on the virtual filename and it leads to GetByPath() in ReadPvr() that also triggers on the virtual filename so having two approaches may conflict but I'll see what I can do.

Martin

[emveepee]

you're going to have to do this based on the metadata that is available and not based on the (virtual) filename, and add methods for retrieving the edl to the pvr api.

I've tried to do this but it always comes back to changing the pvr:// virtual file for specific provides the safest way to not impact other http streaming files. XBMC baseline is full of references to other virtual pvr filename so I don't understand why you have this requirement.

Martin

[zigzag930]

Was this ever implemented? Would be very appreciated for com skip users.....