[jez]

Graeme, good to see you're not one of those slow idiots. So here's the guide for quick idiots:

0) Ensure you're running a recent version of MP - I've tested this against MP1.0 RC3, but RC4 has now been released.
1) If you want to play recordings (rather than just live TV) you need to share the folder where your recordings are located. In my case, I've shared "D:\Team MediaPortal\Media Portal TV Server\recordings" as "MediaPortal". Check that you can browse to "smb://tvserver/mediaportal" from XBMC's file manager (or add a share to Videos if you want).
2) Mosey on over to the subversion repository and get the plug-in, either by svn check-out from https://svn.sourceforge.net/svnroot/...ns/XBMCServer/, or use the viewer by browsing to SourceForge.net Repository - [mp-plugins] Index of /trunk/plugins/XBMCServer and click on "Download GNU tarball". If you used the second option, extract the tarball.
3) You should have a "TVServer" folder. This gets moved to your XBMC device, into plug-ins\Video\ so you should have something like Q:\plug-ins\Video\TVServer\default.py and so on.
4) Then get the TVServerXBMC.dll file and copy onto your MP TV Server into "Team MediaPortal\MediaPortal TV Server\Plugins\" folder.
5) Restart the TV server, run the configurator for it, enable the plug-in, restart again, and it should work.

The bin/Release directory had the DLL file. But bin is no longer in subversion. If you check out revision 2332 you'll get the DLL you need.

Or if Subversion is too difficult for you, get the files from: http://tools.rebel-it.com.au/mp-xbmc/. This includes a .EXE version that can be run stand-alone without installing a plug-in to the MP server, and shows some useful information for troubleshooting. But it displays a console window and you have to run it manually prior to using the XBMC side of things, and you have to stay logged in on the MP server host.

[swifty]

Thanks for the great work Jez, this is working well for me.
Hopefully Alcoheca will have the GSoc stuff ready soon then the work for MP TV Server itegration can begin
One day we will have the awesome XBMC with a real EPG and TV abilities.... one day

[jez]

Finally, some feedback! Thanks Swifty, I'm glad it's working for you.

There's been nothing new on this for quite a while, and I expect it to stay that way, because it all seems functional and stable, and we'd all rather work on the new PVR interface when it arrives.

[Redth]

I just tried using it too

It's working for the most part.. I'm only using Live TV, I could care less about recordings for now.

Anyways, I finally got it streaming live tv somehow (for the longest time it just wouldn't start streaming), however it won't stop timeshifting... Here's the error in my logs from choosing a '--Stop Timeshifting' entry:

2009-01-05 20:50:46.375500 [15]: TVController:ValidateTvControllerParams - incorrect parameters used! user TvControl.User cardId -1 _cards.ContainsKey(cardId) == False CardPresent(cardId) False
2009-01-05 20:50:46.375500 [15]:    at TvService.TVController.ValidateTvControllerParams(User user)
   at TvService.TVController.StopTimeShifting(User& user)
   at MPTvClient.TVServerController.StopTimeShifting()
   at TVServerXBMC.XbmcServer.Stop()
   at TvService.TVController.DeInit()
   at TvService.Service1.OnStop()
   at System.ServiceProcess.ServiceBase.DeferredStop()
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
   at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Otherwise, it's great! I mean yeah EPG would be fantastic, but this will suffice until the unified pvr interface is ready and some real work can begin! Thanks so much for your work, if you can get timeshifting to stop for me (I'm using RC4 btw), I'd be very happy! As it is now, choosing a different channel does work, but since timeshifting never stops, it goes back to the beginning of timeshift buffer whenever you change channels...

Let me know if I can help debug anymore.. I'm proficient in c# and know a little bit about the mediaportal api... Thanks again!

[jez]

Sorry Redth, I can't tell what's not working right from your log. I didn't write any of the LiveTV code, so I'm unfamiliar with how the "stop timeshifting" option works, and I'm also not familiar enough with the MP API to say what could be wrong. I don't use the LiveTV at all (except once when I was just playing around, and I had lots of trouble getting it to work.)

I'd welcome your assistance. Perhaps check out the MP code and have a look through for how it does timeshifting internally. It's possible that the MP API has changed since the current LiveTV plug-in code was written.

[Redth]

Yeah that was my first thought, that the API changed.. I'll dig into it a bit...

So jez, did you write the python script then? I had considered an attempt at getting this working awhile back, but I really am not good enough with the python/xbmc side of things. Perhaps if you are good at that part we could collaborate in the future when the unified pvr interface comes out?

In the meantime I'm going to try and fix the tv server plugin

I'm going to try 1.0 Final and see if I have the same issue...

[Redth]

I've been thinking a bit more... Wouldn't all of this be way easier if we just built a TV Server plugin that exposed the MythTV Protocol? I'm sure there's obstacles I haven't thought about yet, but does anyone see any impossible challenges in going this route?

Right away the only major pitfall I see is that in emulating mythtv backend, we limit tvserver to what mythtv can do, and have to try and map 1:1 in capabilities.... Though, the unified pvr is targetting mythtv to start anyways so likely this would be the case no matter what...

Also, the video streaming may be a difficulty... looks like myth points to just a mpg file to pull in as the stream... not sure if we'll have problems here or not...

[Redth]

Still getting the same error in the 1.0 Final build of MP...

Now, StopTimeshift() is the only thing called, so either that's not the appropriate way to do it, or there's a bug in MP...

[jez]

I think you're suggesting we use a MythTV front-end on XBMC to access a MythTV "shim" on the MP server. For me, it seems like way too much innovation! I really haven't done much coding on this MP/XBMC project - I've simply taken other peoples' work and tweaked it a little. I'd imagine it'd be a fair bit of work (for me) to understand the MP API as well as the MythTV protocol, let alone write some code in C# (not my native language) to translate.

But if you have the skills, I imagine it's doable. Bear in mind that the MythTV scripts/plug-ins in XBMC might not talk MythTV completely - I think they do MySQL calls for program information, and use samba to "stream" the content. This means emulating MythTV on the MP server is not sufficient - you need to emulate a MythTV server, with exposed SMB and MySQL protocols.

Yes, perhaps a bug. If that's the case, I'd expect a MP front-end that remotely enables/disabled timeshift would also have the same problem. Are you able to test this?

[Redth]

Yeah the more I thought about the MythTV shim idea (that's a good way to describe it), the more I realized it was a lot less practical. It appears the mythtv protocol kinda sucks and half the stuff the MythTV front end does is by connecting directly to the backend mysql database.

Here's the issue. I'd love to start making a proper front end for xbmc to tvserver, I just can't do the xbmc/python side. I can handle the TVServer plugin... The one there is a great start, and I'm confident I could make the tvserver plugin side of things do whatever the front end needed...

So, jez, I'm not sure what your capabilities here are, but would you be interested in doing the Python side of things? Or anyone else for that matter?


As for the current error I'm getting, I think I found the solution. Basically, when StartTimeShifting gets called, it gets passed a new User object, and a VirtualCard object as an out parameter. The plugin for TVServer currently does nothing with that VirtualCard when it *should* assign the user object the Id from the VirtualCard if timeshifting started successfully. This way, the User.cardId will not be -1 when StopTimeShifting is called, as this is what's causing the error.

Here's the patch I've made (I'll test it later, I can't from where I am right now, but it does compile.):

Index: ServerInterface.cs
===================================================================
--- ServerInterface.cs	(revision 2493)
+++ ServerInterface.cs	(working copy)
@@ -77,6 +77,9 @@
             {
                 _isTimeShifting = true;
                 rtspURL = vcard.RTSPUrl;
+
+				//Need to keep track of the card the user is timeshifting with or StopTimeshifting breaks
+				me.CardId = vcard.Id;
             }
             return result;
         }