Hauppauge HD-PVR & Colossus Support (4 Viewers)

[David Abineri]

Here is the tv server log

 

[mm1352000]

Well, I don't know what your problem is, because the TV Server log says:

[2015-07-10 21:11:24,339] [Log ] [SchedulesDirect EPG Client] [INFO ] - Sucessfully processed 970 of 886 channels
[2015-07-10 21:11:24,349] [Log ] [SchedulesDirect EPG Client] [INFO ] - Starting processing of 19577 schedule entries

In other words, you should have full EPG for 886 channels.

 

[David Abineri]

And hence the question mm.

Why do I have one day of programming (up to 9pm tonight here) and just a couple of the channels with more than this. The date on the computer (and in MP) is correct. In tv server, when I check to "force loading EPG" and then stop and start tv service, this check is not removed?

Where do I look for the solution to this set of circumstances remembering that I just moved from HDMI to Component input to the Colossus.
Thanks, Dave[DOUBLEPOST=1436620163][/DOUBLEPOST]Also, mm,

1. Those programs that are listed for today are recording properly as scheduled.

2. When I manually restart service in tv server the Colossus car is highlighted in red for about 10 seconds.

Hope this helps, Dave

 

[mm1352000]

Dave, I'm knowledgeable but I'm not an oracle. As I said previously, I simply don't know. It's hard enough trying to help from afar... compounded with the fact that you're using a plugin I've never used myself. I know that doesn't help you, but what more can I say? Check the basics. Did you delete all your channels as instructed prior to changing the SD settings?

 

[David Abineri]

Suddenly, this morning, everything is working fine and the EPG is fully loaded. I don't know why it decided to load now and not yesterday?

But thanks for all the help, it is appreciated. Dave

 

[davidpmays]

David, once before I ran into a problem when I was deleting and rescanning channels. Like you, it said I had a full schedule but would not display. What I discovered was group numbers, not names, were messed up and TV Guide would not display all my information. There are two ways to fix this mess of which I am aware. One download install and setup sql workbench 6.0, create a connection to your MediaPortal database, open database mptvdb, table channelgroup and modify the sort order. Maybe @mm1352000 knows a way to do this in TVserver? The other way is to uninstall and delete all database information and setup it up again. I found workbench solved my problems especially when my cable company would change channel names and SD had not received an update. Workbench allowed me to pull up SD output and copy the two index fields and update my channels. For a while, they were making changes every 3 or 4 months. See my attachment, notice the sort order has 9999 for each of my groupings. When TV Guide was messed up they had numbers ranging from 9990-9999. I had created several extra groups, my wife's favorites, channels with poor reception, Spanish, ... You get the picture, then every few months things would change and the index numbers got real screw balled.

 

[mitchellmedia]

Good evening all
I'm in the process of moving from DVBLink to MediaPortal. I'm seriously impressed with how this has developed over the years. I'm now using TVServer as the backend to my 3 RPi Openelec clients. I have a Colossus card, an IR blaster and Webgrabplus - all working and streaming my Australian cable provider around the house. And while adding all the channels will still take me some time, the initial process was very quick - helped in large part by this thread.

I have only one remaining issue. It first appeared around page 30 in this epic thread and then repeats every few pages. Some channels from my cable provider are encoded in AC3 others in AAC. The IR blaster process runs separately (and more slowly) than the TVServer (or TS writer?) process - and grabs a little bit of the previous channel at the start of the stream. That's no problem if the previous channel had the same encoding. But as other have pointed out - if the two are different, you end up with no audio in most clients (VLC was the only way that managed the 'hostile' stream takeover in my testing).

Page 88 of this thread got close to a solution with MM offering to create a patch (and one was attempted at post 874) - but then all went silent as other issues were discussed and no feedback was provided to MM on his questions of the best way to proceed. (Another user raised it again on page 93, post 927).

Can we please look at this again? I think the solution is a small delay to allow the blaster process to complete and the cable box to start producing the real stream you want to record.

After reading 112 pages of thread - I've got to say the support here is very good! Happy to provide logs and sample video files if required - but I think the issue is pretty well understood now.

Many thanks!

 

[mm1352000]

Hello and welcome mitchellmedia

I must say: to have read all 112 pages shows extreme dedication!

Your summary of the situation generally matches my memory pretty well. However there are a few key pieces of information which I'm not sure if you have understood correctly. I'm going to try to explain them below. It's been a very long time since this problem has been mentioned, so please forgive and correct me if I don't get the details 100% right.

First, the files/streams that the Colossus and TV Server are producing are 100% compliant with the relevant technical standards. I'm very confident there's nothing "hostile" or dodgy about them. I'd expect any reasonable hardware or software to be able to play them.

Second, my recollection is that MediaPortal was only having trouble with live streams, and that the problem was caused by the STB's channel change delay. For a certain period of time the STB and/or Colossus was not producing any output. This was causing MediaPortal's TsReader (and/or TV Server's streaming server) to give up on playing/delivering the stream. That STB channel change delay doesn't apply when playing recordings, so I wouldn't expect problems playing recordings.

With regard to mitigating or eliminating the problem...
1. My recollection is that there was only trouble with client-only installations. If MediaPortal and TV Server were installed on the same PC then there was no problem.
2. I further recall that using UNC paths instead of the default RTSP streaming (previously a "debug" setting, now an advanced setting) as the "time-shifting protocol" eliminated the problem for at least some people. At the time using UNC paths introduced another problem (something related to the caching behaviour of the Windows implementation of the SMB file sharing protocol). However, my understanding is that the UNC paths problem has subsequently been eliminated, making it a viable solution.
3. As indicated in previous discussions about this problem, I'm very reluctant to introduce a delay in the TV Server tuning process for various reasons. A fixed delay is an effective solution, but rather crude. A variable delay is more desirable, but very complex (if not impossible) to implement within the current code framework.
4. A month or two ago I updated the library that MediaPortal and TV Server use for RTSP streaming. This is the first update of that particular component in more than 5 years. The update hasn't yet been integrated into a release, but I am able to provide patches.

Until today I had assumed the problem had been resolved. After all, I haven't seen any reports or references for years. Of course problems don't just solve themselves. My standing assumption would be that the problem was eliminated by the steady stream of TsReader improvements that have come in since the posts you referred to.

That brings me to another point: I had always thought that this problem was a MediaPortal (TsReader) problem rather than a TV Server problem. I couldn't and still can't prove that; it's just an informed opinion. However, your successful test with VLC seems to support that opinion. I mean: if the problem was with TV Server or the files/streams it produces, surely VLC wouldn't work.

As a logical consequence of the above opinions, I'm inclined to think that the problem you're experiencing is due to limitations or issues in OpenELEC rather than an issue in TV Server. Again, I have no way to prove that except the circumstantial evidence which is outlined above.

What can I do to help?
Unfortunately I have zero experience with OpenELEC. That means I'm unable to help debug the problem properly.

The only thing I feel able to do for you that might help is point you to the streaming server patch that I mentioned in (4) above. It's here:
https://forum.team-mediaportal.com/...tively-refused-it.129178/page-10#post-1148645

To install it, stop the TV Server, download and extract the replacement DLL into your TV Server install directory (don't forget to take a backup first!) then start the TV Server again. I have no idea if it will help or not.

You mentioned that you think the solution would be to add a delay in the TV Server tuning process. Considering that TV Server currently doesn't appear to be at fault, I'm currently not willing to do that. Sorry. It isn't my intention to frustrate. Note that if you're really desperate, you may be able to hack the code for yourself. I already provided directions here:
https://forum.team-mediaportal.com/...vr-colossus-support.94850/page-30#post-747830

The relevant code is here:
https://github.com/MediaPortal/Medi...ions/Analog/Graphs/HDPVR/HDPVRChannel.cs#L149

Regards,
mm

 

[mitchellmedia]

Hello and welcome mitchellmedia

Thanks, glad to be here - and even happier to have received such a detailed reply. Yes, I know that reading all of this thread is a little on the extreme side! But I was very keen to do the groundwork myself and ensure that I had a good grasp of the issue, what had been tried before and to demonstrate some effort in the hope that'd get a response. And it did - so thank you very much. We're not too far off the same page. Let's work through it.

First, the files/streams that the Colossus and TV Server are producing are 100% compliant with the relevant technical standards. I'm very confident there's nothing "hostile" or dodgy about them. I'd expect any reasonable hardware or software to be able to play them.

Yep, no issue here. My use of the word hostile was stolen from a conversation you had back in 2011 on this issue and referenced the output of the cable box, not the behaviour of your software. Colossus is doing the right thing, TV Server is doing the right thing.... we'll get to what's not quite right in a moment. But you're correct - this issue is solely about slightly changing the behavior of TV Server to assist the clients that can't cope with a change of audio encoding mid-stream.

1. My recollection is that there was only trouble with client-only installations. If MediaPortal and TV Server were installed on the same PC then there was no problem.

I can't comment on a single-seat Mediaportal setup. My media goes all over the place to ipads, Droids and the Openelec setup. I don't think that's uncommon these days - people are taking their media everywhere. So while I can appreciate the general "client issue" refrain, as none of these clients (other than VLC) handle a change of audio encoder mid-stream I'm hoping to be able to work through a solution (even if it is a crude/blunt delay). But I acknowledge that this issue could be viewed as being a problem with the other software clients (to be honest, I'm surprised that I couldn't find a way to fix this in Kodi - I take your point above that any reasonable software/hardware should be able to cope - but in my testing that doesn't appear to be the case).

2. I further recall that using UNC paths instead of the default RTSP streaming (previously a "debug" setting, now an advanced setting) as the "time-shifting protocol" eliminated the problem for at least some people. At the time using UNC paths introduced another problem (something related to the caching behaviour of the Windows implementation of the SMB file sharing protocol). However, my understanding is that the UNC paths problem has subsequently been eliminated, making it a viable solution.

This point confused me a bit - which I'm sure is my issue, more than your explaining of it. My understanding is that by using the Kodi PVR plug in, I'd be using the UNC paths. And even then, I'm not sure that this would fix the issue as it appears in recordings too - it's just about when stream capture starts - regardless of whether it is then written to a recording file or a timeshift file for live viewing. The issue occurs regardless of whether its a recording file with two types of encoding in it, or a live timeshifting file. Perhaps I've just demonstrated that I didn't understand your point?

3. As indicated in previous discussions about this problem, I'm very reluctant to introduce a delay in the TV Server tuning process for various reasons. A fixed delay is an effective solution, but rather crude. A variable delay is more desirable, but very complex (if not impossible) to implement within the current code framework.

Yep, I can appreciate that slowing down tuning for everyone isn't going to be the answer here. So I know that the best I'm going to get is a patch. Or potentially in future releases an ability in the UI to set a ms number for the delay. While I might spend hours playing with these things and I really enjoy it - I'm by no means any good at it! So I don't actually know the coding effort involved here - so please forgive me for any naivety.

4. A month or two ago I updated the library that MediaPortal and TV Server use for RTSP streaming. This is the first update of that particular component in more than 5 years. The update hasn't yet been integrated into a release, but I am able to provide patches.

That's my hope. I wouldn't have expected a ton of development on this component - in my testing and mucking around with it, it's rock solid and much faster (too fast that's the issue!) than anything else I've used to date.

Until today I had assumed the problem had been resolved. After all, I haven't seen any reports or references for years. Of course problems don't just solve themselves. My standing assumption would be that the problem was eliminated by the steady stream of TsReader improvements that have come in since the posts you referred to.

It looks like the improvements over the years have certainly fixed some of the issues. For other people, it looks like they've come up with other workaround like using the RCA inputs or setting the cable box to only output AAC. Which means you always get sound, but it means that you've lost any chance of surround sound - and I think we can do better than that.

That brings me to another point: I had always thought that this problem was a MediaPortal (TsReader) problem rather than a TV Server problem. I couldn't and still can't prove that; it's just an informed opinion. However, your successful test with VLC seems to support that opinion. I mean: if the problem was with TV Server or the files/streams it produces, surely VLC wouldn't work.

As I've said above, I think we've proven that there isn't an issue with your software. Whether its writing timeshift or a recording file, your software just happily writes down what it receives from the Colossus. I'm not suggesting any change to any of that.

As a logical consequence of the above opinions, I'm inclined to think that the problem you're experiencing is due to limitations or issues in OpenELEC rather than an issue in TV Server. Again, I have no way to prove that except the circumstantial evidence which is outlined above.

What can I do to help?
Unfortunately I have zero experience with OpenELEC. That means I'm unable to help debug the problem properly.

Your logical conclusion is entirely fair and accurate. It is absolutely open to you to say that if the Colossus capture is working and TsReader is working and the files its producing are fine - then go find yourself a client that can deal with the output. I get that. However, I would counter that it's not just one client/software - in my testing the client/software that can't handle the change in encoding is any of the Kodi installations across mac, openelec, ipad and droid, goodplayer on droid. In fact, video redo crashes when I try and skip across the change in encoding format too. So while MediaPortal single seat setup my handle it perfectly fine, given that we're in a world where media is enjoyed in many locations across many clients - I hope that we can work through a solution that works for the majority (?) that can't handle mid-stream changes in encoding.

In my situation at least, the stream only ever ends up with two different types of audio encoding during a channel change. From there, the output from the channel doesn't change - so it's only the first 1000ms that are causing the issue. So regardless of how crude the solution may be, it does seem to scream out as the most appropriate solution.

The only thing I feel able to do for you that might help is point you to the streaming server patch that I mentioned in (4) above. It's here:
https://forum.team-mediaportal.com/t...tively-refused-it.129178/page-10#post-1148645

To install it, stop the TV Server, download and extract the replacement DLL into your TV Server install directory (don't forget to take a backup first!) then start the TV Server again. I have no idea if it will help or not.

Happy to try that - will do so tonight.

You mentioned that you think the solution would be to add a delay in the TV Server tuning process. Considering that TV Server currently doesn't appear to be at fault, I'm currently not willing to do that. Sorry. It isn't my intention to frustrate. Note that if you're really desperate, you may be able to hack the code for yourself. I already provided directions here:
https://forum.team-mediaportal.com/t...vr-colossus-support.94850/page-30#post-747830

The relevant code is here:
https://github.com/MediaPortal/Medi...ions/Analog/Graphs/HDPVR/HDPVRChannel.cs#L149

You certainly haven't frustrated me. I can completely appreciate your line of thinking - as I've set out above. My hope is that my additional reasoning here will lead to your working your magic on a crude delay patch. I'm going to look at your instructions, but to be honest, I'm almost certainly going to be out of my depth. I'm an economist by day and haven't coded a line in my life (unless your code resembles Commodore 64 basic from about 1985?)

Really appreciate the time you've taken to respond and set out everything.

 

[mm1352000]

Thanks for your understanding - I really do appreciate it.

I'll try to keep this response a lot shorter. Please let me know if I overlook anything you'd particularly like me to respond to.

My use of the word hostile was stolen from a conversation you had back in 2011

Ha - that'll teach me to be careful with the words I use!

This point confused me a bit...

Hmmm, very interesting. I think you've understood perfectly. Honestly, I don't recall the issue affecting recordings in the past, but that's a detail that I could be wrong about. I accept your report.
With regards to KODI: I think it may use UNC paths in some cases and RTSP in others.

However, I would counter that it's not just one client/software - in my testing the client/software that can't handle the change in encoding is any of the Kodi installations across mac, openelec, ipad and droid, goodplayer on droid.

I'd expect KODI is using common code across platforms, so if one platform fails they'll all fail. It's surprising really because in DVB TV streams (that KODI is presumably expected to be able to handle) it is possible for the stream configuration to change at any time. For example, some channels in the UK change audio stream channel count during the advertisements, or randomly change between progressive and interlaced video stream encoding. Anyhow, I'd appreciate it if you could report your situation and results to the KODI team [if you haven't done it already] so they can decide whether they consider the behaviour to be an issue worth fixing.

In fact, video redo crashes when I try and skip across the change in encoding format too.

Wow, that's a bit of a surprise too. Again I'd encourage you to report this. The VR guys really seem to know their stuff. My guess is that their code can handle changing audio configurations... but not a change in encoding on a single PID (stream). Really, Hauppauge would have been better to use one stream/PID for AAC audio and another for AC3/DD audio.

So while MediaPortal single seat setup my handle it perfectly fine, given that we're in a world where media is enjoyed in many locations across many clients - I hope that we can work through a solution that gives works for the majority (?) that can't handle mid-stream changes in encoding.

Yes, that's a fair point.

My hope is that my additional reasoning here will lead to your working your magic on a crude delay patch. I'm going to look at your instructions, but to be honest, I'm almost certainly going to be out of my depth. I'm an economist by day and haven't coded a line in my life (unless your code resembles Commodore 64 basic from about 1985?)

C# is quite different to Basic... so please let me know if the attached patch works.
Disclaimer: I don't intend to provide support for this patch in the long term. However, it should remain compatible with future versions of TV Server for the foreseeable future.