[KenV99]

Hi,

I'm going to be installing an HDHomerun Prime tomorrow and have Comcast as my cable provider. I am a very, very light live tv viewer and mostly I would be wanting to record a few recurrent shows and then watch them at a different time. Looking at all of the various choices, it is not very clear to me why I might choose one backend over the other. After reading through a large part of the posts, it seems that the one thing I need is margro's latest build. The other thing that seems clear is that if I want to record premium content, like HBO, I need to do that directly in WMC. I was hoping then that I could add whatever folder those .wtv files go into XBMC as video-tv folders and they would appear in XBMC like the rest of my TV stuff which consists mostly of BR rips of entire series. Is that the case?

Beyond that, it seems that there for particular backends there may be OS availability issues, hardware compatibility advantages, performance advantages, EPG advantages, file compatibility advantages, ease-of-setup advantages, etc., but I haven't been able to find very many comparisons beyond individuals championing one over the other. I thought about looking at how actively any particular one was being developed, but thought that activity might also indicate problems while silence might indicate stability. But I could be wrong.

I have been thinking of using either the WMC backend approach or perhaps mediaportal or N-PVR. The only thing that I don't like too much about WMC is the .wtv format, but I was hoping for 'copy-freely' content, I could use something like MCEBuddy to convert to mp4, if I go that route.

Any guidance would be most appreciated.

[krustyreturns]

Hi,

I only have experience with the wmc pvr solution. The main advantage of it is simpler setup because it uses the wmc setup, free epg, and it works side by side with wmc. But I am biased, so you know, consider the source.

You only want the margro build if you are going to actually watch live-tv, its main advantage is that it speeds up channel changing for some of the pvr solutions.

You can use the wmc pvr solution to record drm'd content, but xbmc can't play it back (at least in the US), only wmc can do that. If its all copy-freely though, there is no problem.

If you use wmc to record wtv files and then put these in a video folder so they show up with the rest of your ripped library this will work - however xbmc will not be able to scrape for metadata for these wtv files, because it doesn't know how to read the crazy names wmc uses for wtv. If you insist upon using it this way, then look into some of the wtv renamer programs that are available, or rename the files manually. Most of my users, use the wmc pvr to display these recordings, but then they will show up in the 'recordings' section of LiveTV in xbmc, instead of the regular video library (but the metadata will be correct).

[KenV99]

Hi,

I only have experience with the wmc pvr solution. The main advantage of it is simpler setup because it uses the wmc setup, free epg, and it works side by side with wmc. But I am biased, so you know, consider the source.

You only want the margro build if you are going to actually watch live-tv, its main advantage is that it speeds up channel changing for some of the pvr solutions.

You can use the wmc pvr solution to record drm'd content, but xbmc can't play it back (at least in the US), only wmc can do that. If its all copy-freely though, there is no problem.

If you use wmc to record wtv files and then put these in a video folder so they show up with the rest of your ripped library this will work - however xbmc will not be able to scrape for metadata for these wtv files, because it doesn't know how to read the crazy names wmc uses for wtv. If you insist upon using it this way, then look into some of the wtv renamer programs that are available, or rename the files manually. Most of my users, use the wmc pvr to display these recordings, but then they will show up in the 'recordings' section of LiveTV in xbmc, instead of the regular video library (but the metadata will be correct).

Thanks. That info was very helpful. I didn't realize that I couldn't watch the drm'd content in XBMC. I'll likely rename the copy-freely files myself since the volume is relatively low. I was think of the margro build mainly because I wanted to save myself the frustration of slow changing on those rare occasions that I did watch and while I was testing things during the setup phase. Are there any disadvantage to using that build?

[krustyreturns]

I have heard that some addons don't work with it, but its not something I have direct experience with so I can't tell you which ones. I think at least part of the reason it was not included in the proper xbmc build is due to this though.

[KenV99]

I have heard that some addons don't work with it, but its not something I have direct experience with so I can't tell you which ones. I think at least part of the reason it was not included in the proper xbmc build is due to this though.

OK, good to know. I may see how well I can tolerate any channel changing delays with my stock 12.3 before switching. Can you clarify something, however? If I schedule a recording from within XBMC, does XBMC run a background process and then initiate the recording at the appropriate time or is the backend responsible for scheduling and initiation?

If the backend takes care of all of this, it may steer me towards a backend that can use SchedulesDirect since that is reportedly more up-to-date for schedule changes than any of the other EPG's.

[krustyreturns]

Xbmc never schedules a recording, it makes a recording request to your backend, and the backend schedules it and records it.

Your EPG requirement is a key piece of data to help with your decision, because the wmc/serverwmc solution does NOT use SchedulesDirect, and its probably the only one that doesn't.

Good luck with whichever backend you choose.

[TugboatBill]

When it comes to channel switching speed this thread is the definitive source:
http://forum.xbmc.org/showthread.php?tid=182267

It really should be sticky'd