(2013-09-09, 01:07)lennon105 Wrote: [ -> ]HD = yes. Same problem as you. SD is ok.
Which version of xbmc are you running? I was running the margo version, I switch back to the default 12.2 and no longer having video issues.
While using the margo version I was able to change channels within 6 seconds, but with the default 12.2 version I'm back to 10 seconds.
This wins for ease of setup! I only use it for live TV and it's been working really nice.
Just one issue. I only have ~ 35Gb of free disk space, seems after a few hours this fills up and the video will just freeze. It's a minor inconvenience to stop the stream and restart just wanted to bring it to your attention. Sorry if this has already been discussed.
Many thanks for the add-on.
(2013-09-09, 14:49)divingmule Wrote: [ -> ]This wins for ease of setup! I only use it for live TV and it's been working really nice.
Just one issue. I only have ~ 35Gb of free disk space, seems after a few hours this fills up and the video will just freeze. It's a minor inconvenience to stop the stream and restart just wanted to bring it to your attention. Sorry if this has already been discussed.
Many thanks for the add-on.
the way this backend/addon work is that when watching live TV it is actually having WMC record the livestream, and then remuxing it to ts and streaming that to your XBMC. In other words, the longer you watch live TV on the same channel, the more hard drive space it will use up (it deletes the live TV iun progress recording as soon as you change channels etc). The approach of this addon is not great for disk space, however this does provide other benefits such as being able to record to the start of the live buffer or current show, when you hit the "record" button, rather than only recording from the point where you hit the button as some other PVRs/addons do. In my case, my HTPC has a small SSD so I have iSCSI mounted a 250GB D: drive from my NAS.
(2013-09-09, 01:24)hoopsdavis Wrote: [ -> ] (2013-09-09, 01:07)lennon105 Wrote: [ -> ]HD = yes. Same problem as you. SD is ok.
Which version of xbmc are you running? I was running the margo version, I switch back to the default 12.2 and no longer having video issues.
While using the margo version I was able to change channels within 6 seconds, but with the default 12.2 version I'm back to 10 seconds.
So you feel confident you have isolated the problem to the margo version of xbmc?
(2013-09-07, 20:49)Groove93 Wrote: [ -> ]Tested the WMC server today. Far more stable than NextPVR and MediaPortal regarding my set up which consists of an HD HomeRun dual ota tuner, and two Hauppage USB tuners. Channel logos were imported as well.
Yes it is slow when changing channels, but my only issue that I'm concerned about is Dolby Digital audio for Broadcast TV. This seemed to have broken my ability to play Lossy Audio for both love tv and my movies.
I adjusted the audio settings within XBMC to disable Dolby Digital, DTS, and AAC support. This fixes playback for live tv, movies, and recorded tv shows, but of course those audio formats are gone.
I decided to disable the WMC plugin and go back to NextPVR until this can be resolved. I use WMC for live broadcasts by default because Live TV within XBMC is too sensitive when it comes to weak ota signals and crashes far too often as a result.
Keep up the good work guys because this is very promising!!!
I'm not sure I understand your post regarding the audio, so see if this applies: I currently only mux in one audio track (the first the remuxer finds) into the output stream. The was partly for debugging and partly because I wanted to get the stream going as fast as possible. I always meant to put it back in, so thanks for the reminder. It this isn't what you are talking about let me know.
(2013-09-07, 23:36)stevedawg85 Wrote: [ -> ]It was working for me last week, but was working on other XBMC settings and closed the server. Now I'm starting the server today and receive:
"Error on device" HDHomerun Prime-Tuner xxxxx-0, 1, & 2" can't load channels"
I click OK
"No c hannels found in WMC database, set up WMC and try again.
My WMC works normally w/ no problems. My "Other XBMC settings" I was working on was exporting channels as .strms and configuring channels w/ PseudoTV Live. Sort of related, but I dont think caused it to stop working do u?
I have been working on this pvr to wmc deal for a long time and I did have this happen to me once. I don't know what caused it either. To fix it, I had to rerun the wmc's tv setup (rediscover tuners and channels). I know that is a pain, but never having experienced it again so I never got to the bottom of it.
(2013-09-09, 15:08)scarecrow420 Wrote: [ -> ] (2013-09-09, 14:49)divingmule Wrote: [ -> ]This wins for ease of setup! I only use it for live TV and it's been working really nice.
Just one issue. I only have ~ 35Gb of free disk space, seems after a few hours this fills up and the video will just freeze. It's a minor inconvenience to stop the stream and restart just wanted to bring it to your attention. Sorry if this has already been discussed.
Many thanks for the add-on.
the way this backend/addon work is that when watching live TV it is actually having WMC record the livestream, and then remuxing it to ts and streaming that to your XBMC. In other words, the longer you watch live TV on the same channel, the more hard drive space it will use up (it deletes the live TV iun progress recording as soon as you change channels etc). The approach of this addon is not great for disk space, however this does provide other benefits such as being able to record to the start of the live buffer or current show, when you hit the "record" button, rather than only recording from the point where you hit the button as some other PVRs/addons do. In my case, my HTPC has a small SSD so I have iSCSI mounted a 250GB D: drive from my NAS.
There are ways to mitigate this if it ends up being a big issue for people. I like this solution because I figure disk space is cheap, and on the rare occasions when I watch live tv (go niners!) I want to be able to go back to the beginning, or rec the whole thing once I decide that I wish I could view it over again.
(2013-09-09, 16:58)krustyreturns Wrote: [ -> ] (2013-09-09, 01:24)hoopsdavis Wrote: [ -> ] (2013-09-09, 01:07)lennon105 Wrote: [ -> ]HD = yes. Same problem as you. SD is ok.
Which version of xbmc are you running? I was running the margo version, I switch back to the default 12.2 and no longer having video issues.
While using the margo version I was able to change channels within 6 seconds, but with the default 12.2 version I'm back to 10 seconds.
So you feel confident you have isolated the problem to the margo version of xbmc?
Yes Krusty, I'm pretty sure I've isolated the video issues I experienced to the margo version of xbmc. I've tested a few times goinng from one version to the other and each time using the margo version the video issues return. The down side is, with the margo version I get much better channel change speeds, 6 - 8 seconds. with the default version I get 11 to 13 seconds.
(2013-09-09, 17:50)hoopsdavis Wrote: [ -> ] (2013-09-09, 16:58)krustyreturns Wrote: [ -> ] (2013-09-09, 01:24)hoopsdavis Wrote: [ -> ]Which version of xbmc are you running? I was running the margo version, I switch back to the default 12.2 and no longer having video issues.
While using the margo version I was able to change channels within 6 seconds, but with the default 12.2 version I'm back to 10 seconds.
So you feel confident you have isolated the problem to the margo version of xbmc?
Yes Krusty, I'm pretty sure I've isolated the video issues I experienced to the margo version of xbmc. I've tested a few times goinng from one version to the other and each time using the margo version the video issues return. The down side is, with the margo version I get much better channel change speeds, 6 - 8 seconds. with the default version I get 11 to 13 seconds.
The new release will do better speed wise, but that is disappointing. It still might be worth testing the new release with this build just in case the change on the client side does fix it, but thats a shot in the dark. I hope to get it out tomorrow. Thanks for testing this.
Krusty, one thing I would like you to look at when you get time (Not a major issue but would be nice) As I've mentioned before, when running the mediaportal backend, as server/client, I can tune to a channel in my bedroom (Server/Clent) and go to the living room (Client2) and tune to that same channel (I think this is possible because of the timeshift file created in mediaportal) But with wmc_server if I try the same, on the second client (living room) I get the message telling me the card is busy. I'm aware we're still in the infancy of this backend and I'm sure you'll add more options and possibilities. Now tell me, am I correct that this isn't a possibility with wmc_server yet?
(2013-09-09, 17:58)krustyreturns Wrote: [ -> ] (2013-09-09, 17:50)hoopsdavis Wrote: [ -> ] (2013-09-09, 16:58)krustyreturns Wrote: [ -> ]So you feel confident you have isolated the problem to the margo version of xbmc?
Yes Krusty, I'm pretty sure I've isolated the video issues I experienced to the margo version of xbmc. I've tested a few times goinng from one version to the other and each time using the margo version the video issues return. The down side is, with the margo version I get much better channel change speeds, 6 - 8 seconds. with the default version I get 11 to 13 seconds.
The new release will do better speed wise, but that is disappointing. It still might be worth testing the new release with this build just in case the change on the client side does fix it, but thats a shot in the dark. I hope to get it out tomorrow. Thanks for testing this.
Sure once you release the new build I'll test it on both the margo version and the default version and give feedback. (Check your PM)
The magro build has a 1 line "fix" in it to tell XBMC not to wait too long when attempting to identify the stream that is sent to it when using live TV. Otherwise the stock XBMC waits several seconds. All of this happens after the WMC backend has recorded the live stream, remuxed to TS and then sent it to XBMC as a stream. So krusty can do as much as he can on the backend/remuxing side, but we really need that XBMC fix to really get the channel change down. Hopefully this fix is included in Gotham but I havent looked as yet. Most likely these Magro builds have other changes in them which we dont really want. I suppose one of us might be able to take the official XBMC frodo build and add just this one change to it and build a version that is identical to the Frodo release, save for just that one channel change speedup. That is assuming of course that this isnt already what magro did (im not sure whether his builds have just this 1 fix or whether they include an assortment of other fixes (some of which may be causing the video issues people talk about). It's also possible that this fix itself causes the issues (eg if it couldnt identify the stream in time but gives up because of the shorter timeout specified). It isnt really a fix as much as it's a hack anyhow. I think another guy did have some actual fixes in the ffmpeg code but it gets confusing trying to follow that discussion and the commits on github etc. What seems to have happened is that a pull request got accepted into XBMC frodo but it turned out to not include all of the required changes, then Frodo got locked down and no more changes could be made.
Anyway the next version should contain krusty's speed ups on the backend so even with XBMC still taking longer than ideal to process the stream, it should still be an improvement for everybody.
I did some considerable refactoring of the ServerWMC code to get it more modular and better equiped for future development, but as with all refactoring this introduces the chance for regressions/bugs. Im hoping that krusy approves my refactoring changes so that when the next build comes out all of our testers will be able to not just check the channel change improvements and other bug fixes but also help identify any problems from my refactoring
hoops. im pretty sure I can see why the 2 clients playing the same channel isnt working at the moment, when the 2nd client wants to watch that live channel. the backend cant record and remux it, because it is already recording and remuxing that channel for client 1. Ideally we could just direct client 2 at the existing remuxed TS file but that would have issues since that stream started from when client 1 started watching that channel. If its possible to send the stream to XBMC as well as an offset of where to play from (and have the frontend client skip to that offset) that would be good. Otherwise perhaps the backend could remux a new TS file for client 2, from the existing wtv live stream that is going. We will file it as a bug request so it doesnt get lost. I imagine that everyone would be keener to get a build with the bugfixes and channel change speedups that have alrady been coded and are just being tested by us, rather than wait even longer for more fixes, so I think we will log this bug but not hold up any release for it at this stage
(2013-09-09, 23:18)scarecrow420 Wrote: [ -> ]The magro build has a 1 line "fix" in it to tell XBMC not to wait too long when attempting to identify the stream that is sent to it when using live TV. Otherwise the stock XBMC waits several seconds. All of this happens after the WMC backend has recorded the live stream, remuxed to TS and then sent it to XBMC as a stream. So krusty can do as much as he can on the backend/remuxing side, but we really need that XBMC fix to really get the channel change down. Hopefully this fix is included in Gotham but I havent looked as yet. Most likely these Magro builds have other changes in them which we dont really want. I suppose one of us might be able to take the official XBMC frodo build and add just this one change to it and build a version that is identical to the Frodo release, save for just that one channel change speedup. That is assuming of course that this isnt already what magro did (im not sure whether his builds have just this 1 fix or whether they include an assortment of other fixes (some of which may be causing the video issues people talk about). It's also possible that this fix itself causes the issues (eg if it couldnt identify the stream in time but gives up because of the shorter timeout specified). It isnt really a fix as much as it's a hack anyhow. I think another guy did have some actual fixes in the ffmpeg code but it gets confusing trying to follow that discussion and the commits on github etc. What seems to have happened is that a pull request got accepted into XBMC frodo but it turned out to not include all of the required changes, then Frodo got locked down and no more changes could be made.
Anyway the next version should contain krusty's speed ups on the backend so even with XBMC still taking longer than ideal to process the stream, it should still be an improvement for everybody.
I did some considerable refactoring of the ServerWMC code to get it more modular and better equiped for future development, but as with all refactoring this introduces the chance for regressions/bugs. Im hoping that krusy approves my refactoring changes so that when the next build comes out all of our testers will be able to not just check the channel change improvements and other bug fixes but also help identify any problems from my refactoring
hoops. im pretty sure I can see why the 2 clients playing the same channel isnt working at the moment, when the 2nd client wants to watch that live channel. the backend cant record and remux it, because it is already recording and remuxing that channel for client 1. Ideally we could just direct client 2 at the existing remuxed TS file but that would have issues since that stream started from when client 1 started watching that channel. If its possible to send the stream to XBMC as well as an offset of where to play from (and have the frontend client skip to that offset) that would be good. Otherwise perhaps the backend could remux a new TS file for client 2, from the existing wtv live stream that is going. We will file it as a bug request so it doesnt get lost. I imagine that everyone would be keener to get a build with the bugfixes and channel change speedups that have alrady been coded and are just being tested by us, rather than wait even longer for more fixes, so I think we will log this bug but not hold up any release for it at this stage
Thanks for the feedback scarecrow. I was telling Krusty pretty much what you just said, I'm not a programmer but I do understand somethings.
I'm sure the next release will satisfy many as far as channel changing speeds.
Is there anyway to take a look at how mediaportal allow the steam to be play on a second client.
Prior to moving to ServerWMC, I was running mediaportal and it allows that recorded stream to play on the second client.
Hey guys. The problem with playing multiple streams is something I broke when implementing the channel change speed ups, I found the problem and it will be fixed on release. Thanks Hoops for catching this.
Thanks to Krusty I can finally watch live TV on xbmc with ease! I also wanted to confirm HD streams on frodo 12.2 play smooth but with longer channel change time. While the Margo build changes faster, my video will studder every 30 to 40 seconds.
Keep up the excellent work, you are the f-ing man!
Here's an issue I'm having: Timeout error
After taking a look at the log file, it appears the .ts file isn't being created.
This is weird because its' only happening on one channel (20.1)
here's what I pulled out of the log:
2013/09/09 20:48:10.769 SetChannel> TuneRequest set
2013/09/09 20:48:10.852 StreamProc> wtv recording started in 0.09 sec
2013/09/09 20:48:10.852 StreamProc> stream output file: LiveTV_ADAVIS_ClearQAM_20.1_2013_09_09_20_48_10.ts
2013/09/09 20:48:10.853 StreamProc> started remux, live stream 'ts' file: LiveTV_ADAVIS_ClearQAM_20.1_2013_09_09_20_48_10.ts
2013/09/09 20:48:10.877 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/09 20:48:11.074 Parse> Guid: 0 took 0.20 sec, it was attempted 86 times
2013/09/09 20:48:11.075 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/09 20:48:20.969 StreamProc> process start error: Stream file 'ts' does not exist, timeout reached. calling Close()
Raspbmc has preliminary WMC PVR support here
http://forum.stmlabs.com/showthread.php?tid=10553 please test and report any issues. Note that these are experimental builds and there may be other issues. Official builds are planned for later this month if all goes well.