2015-05-20, 08:16
Well I guess you are stuck for the moment then. Either consolidate your tuners or adopt the solution proposed earlier.
2015-05-20, 10:00
the commit reverts with trivial conflicts, you can find it on top of current master at https://github.com/notspiff/xbmc/tree/re...sp_removal
note i did no effort to keep the project files working, but linux build should do.
use the source luke.
note i did no effort to keep the project files working, but linux build should do.
use the source luke.
2015-05-20, 10:25
I tried the solution with a second pvr.hts add-on, but without success. I copied the add-on in a different folder and edited the addon.xml(changed the id and name). I configure the second pvr to connect to another tvheadend and restarted the pvr database, but the are some issues with this solution:
- Some of the channels from both servers have the same names and I don't know when I start a channel from which server is it.
- When I switch to channel "A" from the one server(I don't know from which server - same names) it starts. When I switch to the second channel "A" starts channel "Y" not channel "A". I cleaned twice the PVR DB but nothing changed.
- Some of the channels from both servers have the same names and I don't know when I start a channel from which server is it.
- When I switch to channel "A" from the one server(I don't know from which server - same names) it starts. When I switch to the second channel "A" starts channel "Y" not channel "A". I cleaned twice the PVR DB but nothing changed.
2015-05-20, 10:34
First point - why does it matter which server the channel is on?
Second point, no idea sorry.
Second point, no idea sorry.
2015-05-20, 12:19
(2015-05-20, 10:34)nickr Wrote: First point - why does it matter which server the channel is on?
Second point, no idea sorry.
Because my girlfriend and my brother are also watching from my servers and If they don't know from where they are watching they can block a tuner which is important, because some channels are only available from this one tuner.
2015-05-20, 13:55
well, then have the important tuner only provide relevant channels 
2015-05-20, 19:15
(2015-05-20, 10:00)ironic_monkey Wrote: the commit reverts with trivial conflicts, you can find it on top of current master at https://github.com/notspiff/xbmc/tree/re...sp_removal
note i did no effort to keep the project files working, but linux build should do.
use the source luke.
Thanks for the link. To compile Kodi and openELEC is an option for me, but I prefer to not do that. The last time I complied openELEC from source it took me hours for one build. Now I have to compile openELEC for RPi 2, RPi 1, x86 64 bit and Wetek Play. I still hope that the developers from Kodi team restore the dropped functionality, because there isn't an alternative at the moment to use more than one tvheadend backends.
2015-05-20, 21:31
it might come back if we (or let's say spiff ) manage to get VFS (virtual file system) add-ons finished. HTPS protocol is no longer needed for like 95% of the users or more, so why drag it along and have additional support burden? I understand that this is frustrating for you, being affected by this, and I feel sorry about that, but please also understand our position. We're heavily lacking devs (only one active Android and OSX dev for example), so every support burdon we can remove is a small win.
) manage to get VFS (virtual file system) add-ons finished. HTPS protocol is no longer needed for like 95% of the users or more, so why drag it along and have additional support burden? I understand that this is frustrating for you, being affected by this, and I feel sorry about that, but please also understand our position. We're heavily lacking devs (only one active Android and OSX dev for example), so every support burdon we can remove is a small win.
2015-05-21, 07:07
I didn't know that you are a small team. I understand you, because I'm also a developer. I hope you decide to revert the commit, it should be fast even with conflicts or if you decide to go the VFS add-on way it's also a solution(maybe).
I also think that more people use the HTSP client in Kodi, but the most people use the stable versions of Kodi and openELEC and they didn't noticed the change. I myself have 6 devices with Kodi and openELEC on them and only my Wetek is with openELEC 6 and Kodi 15.
I also think that more people use the HTSP client in Kodi, but the most people use the stable versions of Kodi and openELEC and they didn't noticed the change. I myself have 6 devices with Kodi and openELEC on them and only my Wetek is with openELEC 6 and Kodi 15.
2015-05-21, 09:26
* ironic_monkey wonders what da-anda is on about. i'm listening to a sacd iso as we speak (using a vfs addon)...
2015-05-21, 10:08
I think someone suggested the VFS addons weren't ready for prime time yet, but it maybe a case of the right people not having proper time to review due to all the other binary add-on work. If you're happy with the state of the them then I'll prod the Team to take a look and maybe they can be next in line after Visualisations.
2015-05-21, 10:09
(2015-05-21, 09:26)ironic_monkey Wrote: * ironic_monkey wonders what da-anda is on about. i'm listening to a sacd iso as we speak (using a vfs addon)...The last thing I read about VFS add-ons is that you gave up at a certain point. I know that large parts did already work and had been moved to add-ons by you, but I think you said one last thing was missing. Sorry if I'm not up to date on that. I try to follow development as closely as I can so that I can give (at least in my eyes) qualified support, but been a bit too busy the last weeks to keep up with recent changes.
2015-05-21, 10:43
They are fully working, though I haven't finished many of the addons. There's some questionable callbacks (url encoding, dns cache lookups and some other small things that do not belong in callbacks). I had to add these since kodiplatform isn't used as intended yet (used by kodi itself so code can be shared).
As it's not purrrfect (just a good start) and leaves lots of room for do this and this and this and this or we wont merge it, I can't imagine the nightmare you'd have to suffer to get this shit through the gang of goons at github. Since it does what I wanted it to (remove the rar taint on the main app, add sacd support) I'm quite content with what I have. No technical reason. If this was xbmc of old, it would have been available for users 1.5y ago and much improved by now.
The missing bit was the annoying GUI callbacks in some of the vfs (samba for instance). I have almost finished that, just haven't tested it yet.
As it's not purrrfect (just a good start) and leaves lots of room for do this and this and this and this or we wont merge it, I can't imagine the nightmare you'd have to suffer to get this shit through the gang of goons at github. Since it does what I wanted it to (remove the rar taint on the main app, add sacd support) I'm quite content with what I have. No technical reason. If this was xbmc of old, it would have been available for users 1.5y ago and much improved by now.
The missing bit was the annoying GUI callbacks in some of the vfs (samba for instance). I have almost finished that, just haven't tested it yet.
2015-05-21, 11:51
thanks for the heads up - sounds awesome. Yes, I agree that it'll for sure be a hard one to pass github review, but let's hope for the best. IMO if the interface is well defined and there are only a hand full of "hacks" that will be addressed later, it would be good to go as long as no existing functionality is lost.
