home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Talk
Hauppauge HD-PVR & Colossus Support
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="mitchellmedia" data-source="post: 1157227" data-attributes="member: 155706"><p>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.</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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).</p><p></p><p></p><p></p><p>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?</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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.</p><p></p><p></p><p></p><p>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.</p><p></p><p>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.</p><p></p><p></p><p></p><p>Happy to try that - will do so tonight.</p><p></p><p></p><p></p><p>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?)</p><p></p><p>Really appreciate the time you've taken to respond and set out everything.</p></blockquote><p></p>
[QUOTE="mitchellmedia, post: 1157227, member: 155706"] 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. 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. 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). 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? 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. 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. 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. 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. 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. Happy to try that - will do so tonight. 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Talk
Hauppauge HD-PVR & Colossus Support
Contact us
RSS
Top
Bottom