[craigrs84]

I was looking over the source code for the NPVR add on, it looks like it's using HTTP to transfer the video stream.

I started to implement my own PVR add on just for learning purposes and I found that it was much easier to use XBMC built in file class for streaming the file via SMB vs. HTTP. Just wondering if streaming via SMB is a good idea or not. Did the other plugin authors go with HTTP mainly because its more universal, or are there some other advantages?

I'm also interested in learning how to support time shifting, but I'm not sure exactly what is required to support time shifting. I could see how time shifting would be more difficult to implement if using HTTP, but if using SMB to read the file directly couldn't I just seek anywhere I wanted without too much effort? Or are there performance concerns where I constantly need to be buffering extra data?

I realize my questions are sort of open ended, just looking for some general guidelines or best practices. Thanks

[sub3]

I went with HTTP in the NextPVR addon because NextPVR already had all the interfaces for streaming via HTTP, and it made sense to reuse it. It also simplifies setup for a lot of people, since they don't need to create shares etc.

If you're thinking about going down the SMB path, you'll also want to think ahead about how you'll implement your live tv support - ie, you don't just want one big ever-growing file, that'll eventually fill the user's hard drive if they happen to leave live tv streaming for an extended period of time.

[zigzag930]

Would it be possible to create an option in pvr.nextpvr to allow a choice of SMB or http:? This would really benefit those of us that use Comskip. Currently we must resort to 3rd party tools like xnewa or play recordings via video/file rather than the native TV/recordings method. I don't know the specifics, but Kodi's player does not read .edl files when transfer is via http:, so com skip does not work.

[krustyreturns]

We have gone the smb way with our wmc addon - although we added http later - smb is our user's preferred way of running with kodi. We do have the ever-growing file with live-tv, but we get no complaints about that from users (disk space is cheap). We built in a safeguard that auto-kills the stream if the user forgets about it that the user can set. Also it has the advantage of on-the-fly recordings can start from when the user began watching the live-tv stream rather then when they hit the record button.

[zigzag930]

I may not have been clear about my request, so let me try again. I am looking for pvr.nextpvr to use SMB rather than http: for recordings that are already stored, not live.

So, in other words, when shows have been recorded to disk and the .edl file has been created, playback using nextpvr (kodi client) by selection "recordings" plays via SMB instead of http. As the current method streams the recorded shows, .edl files are ignored. Those methods that use SMB for playback, do in fact find and use the .edl files for skipping commercials.

Hope this helps.

J

We have gone the smb way with our wmc addon - although we added http later - smb is our user's preferred way of running with kodi. We do have the ever-growing file with live-tv, but we get no complaints about that from users (disk space is cheap). We built in a safeguard that auto-kills the stream if the user forgets about it that the user can set. Also it has the advantage of on-the-fly recordings can start from when the user began watching the live-tv stream rather then when they hit the record button.

[krustyreturns]

Sorry, I was addressing the OP and I didn't notice that it was an old post.