2014-01-14, 04:51
I've already made the code changes but Im at work so I will need to wait till Im at home to test it 
2014-01-14, 04:57
Awesome, I got behind on putting up the new version of swmc with the mb3 interface. I just did it, so please use that. Also you can get kite's test file on my google drive. The file name is:
LiveTV_htpc-PC_DVB-T_4_2014_01_10_17_44_39.wtv
LiveTV_htpc-PC_DVB-T_4_2014_01_10_17_44_39.wtv
2014-01-14, 17:57
(2014-01-13, 18:16)krustyreturns Wrote: clientxero, are you also getting two 'eng' audio streams, one stereo and one mono?
I will probably just take the easy way out and put in an option to filter out 'mono' audio streams if more than one audio stream is present. I should be able to get it in the next release.
(2014-01-14, 02:42)scarecrow420 Wrote: In my googling I have seen some examples where the visual impaired track is in stereo rather than mono. it would be interesting if there is something else in there that helps identify it. It seems like perhaps in this case, where the impaired stream was stereo, ffmpeg did have "visually impaired" annotated on it. perhaps that string is available somewhere and we could also look for "impaired"
https://trac.ffmpeg.org/ticket/2025
Also here is same problem happening for microsoft tool, havent found info on how to tell correct stream as yet though
http://answers.microsoft.com/en-us/windo...e8548c6d30
That is my situation, both are stereo, with the 1 selected being the visually impaired.
[Edit]
And I see it looks like you guys found a solution, awesome. I still wanted to reply, even though later, as opposed to ignoring your question!
2014-01-14, 18:10
clientxero,
Could you make me a short clip from one of these channels with both audio streams and upload it to my g-drive?
https://drive.google.com/folderview?id=0...sp=sharing
if you do, let me know when it is there and what its name.
Could you make me a short clip from one of these channels with both audio streams and upload it to my g-drive?
https://drive.google.com/folderview?id=0...sp=sharing
if you do, let me know when it is there and what its name.
2014-01-15, 08:04
OK using those flags worked great so the fix is done, without having to resort to counting channels or bitrate etc. In the next build of ServerWMC there will be a configuration option to set whether the remuxer will include hearing impaired audio tracks, which defaults to false.
2014-01-15, 19:22
(2014-01-14, 18:10)krustyreturns Wrote: clientxero,
Could you make me a short clip from one of these channels with both audio streams and upload it to my g-drive?
https://drive.google.com/folderview?id=0...sp=sharing
if you do, let me know when it is there and what its name.
Sorry I didnt get back to you yesterday, do you still need this based on what scarecrow fixed?
(2014-01-15, 08:04)scarecrow420 Wrote: OK using those flags worked great so the fix is done, without having to resort to counting channels or bitrate etc. In the next build of ServerWMC there will be a configuration option to set whether the remuxer will include hearing impaired audio tracks, which defaults to false.
Awesome scarecrow, much appreciated!
2014-01-15, 19:45
If you can. We currently don't have an example of the impaired audio being the same number of channels as the main audio. Scarecrow and I have a library of corner cases, we don't have a sample of this format. Plus, it would be nice just to verify his fix works on one more type (although it sounds pretty bullet proof).
2014-01-16, 01:55
Yeah, always good to get more test files to make sure that the EVENTID_AudioTypeSpanningEvent is present and has those same flags set for the impaired audio track
2014-01-20, 09:53
Ok so got ServerWMC (1.0.0.21 build 1114) running yesterday and the correct audio stream is now selected when watching Live TV.
However when watching recordings back there are some channels where there are two English (stereo) channels. It always defaults to stream 1/2 but the correct stream is 2/2.
I guess recordings are played back via a different mechanism which might need the changes applied also?
If you get a chance to take a look I uploaded "Driving Wars_Dave_2014_01_20_07_44_28.wtv" to your drive as an example.
Thanks for getting the Live TV audio sorted so quickly btw! One step closer to ditching WMC7 as a frontend
However when watching recordings back there are some channels where there are two English (stereo) channels. It always defaults to stream 1/2 but the correct stream is 2/2.
I guess recordings are played back via a different mechanism which might need the changes applied also?
If you get a chance to take a look I uploaded "Driving Wars_Dave_2014_01_20_07_44_28.wtv" to your drive as an example.
Thanks for getting the Live TV audio sorted so quickly btw! One step closer to ditching WMC7 as a frontend
2014-01-20, 11:50
Also, HD channels we get with uk freeview will not play (latest release and also had problems previously). These channels work in WMC itself.
Not sure if this is related - if not may need a separate thread...
Here is the log:
http://pastebin.com/7yFAAAW7
See request to play channel at:
2014/01/20 07:53:24.340 Received client request: htpc-PC|OpenLiveStream|4958734|0|101|BBC One HD
Not sure if this is related - if not may need a separate thread...
Here is the log:
http://pastebin.com/7yFAAAW7
See request to play channel at:
2014/01/20 07:53:24.340 Received client request: htpc-PC|OpenLiveStream|4958734|0|101|BBC One HD
2014-01-20, 12:14
Hi kitehgih,
In response to the first item, the language settings aply when we remux the WTV file to TS. basically they are indicating which streams we are transferring from WTV to TS and we simply drop tracks that dont match the indicated settings (language, hearing impaired etc). My fix sounds like it's working here, if your liveTV playback is now using the correct audio track. Completed recordings however, we just play back the WTV file and here is where the problem lies - the WTV still includes all of the streams and XBMC is selecting the wrong default one it seems. I think we got so focused on enhancing the remuxer to drop these audio tracks for live TV that I didnt really think about the fact that completed recordings will still exhibit the issue, if the audio tracks are in such a way that XBMC picks an audio track that you don't consider the sensible default. We just direct XBMC to play the WTV file so we aren't in control of much at this point, just "play this file". I wonder if it's possible that XBMC's video player needs some enhancements when it comes to WTV files and these hearing impaired audio tracks. It's kind of strange through becase our identification of these streams discussed earlier in this thread is based off ffmpeg source code, which I thought XBMC uses ffmpeg. I guess it's possible that it knows they are hearing impaired tracks but just doesnt have the logic to not select this for playback by default (or have an option to guide audio track selection etc).
There is a workaround you could use for completed recordings - We do have a server option "remux all recordings to TS" which will remux even completed recordings. This was more a troubleshooting option, particularly when it seemed raspberry Pi's had trouble playing large WTV files, but it would also work in your case. Remuxing the completed recording to TS will again cause us to drop the undesired audio tracks and your playback should be OK. The downside may be that you can't skip/fast forward as much as quickly after playback, since the remuxed TS file isn't full size yet. I'd be interested in your experiences with that as for some it seems that the remux job finishes quite quickly and FF/skip isnt much impacted but for others it seems that even after waiting a while, they still cant seem to skip much into the future of the recording.
In response to the 2nd item, this looks like a problem introduced in build 1114 where the audio stream checking is too harsh and ends up dropping all audio streaams then failing with a "no audio streams found" error. Krusty already released build 1115 to fix this, so hopefully that will take care of your BBC One HD problem. Please try 1115 and let us know. If it doesn't work, you know the drill Upload the test flie and we will check it out.
This TV stuff is so different between countries/providers it really is very much like chasing your tail sometimes! I know everyone appreciates our efforts to help, and we appreciate your efforts to highlight your specific cases and provide test files for us to broaden the scope of situations we can handle
In response to the first item, the language settings aply when we remux the WTV file to TS. basically they are indicating which streams we are transferring from WTV to TS and we simply drop tracks that dont match the indicated settings (language, hearing impaired etc). My fix sounds like it's working here, if your liveTV playback is now using the correct audio track. Completed recordings however, we just play back the WTV file and here is where the problem lies - the WTV still includes all of the streams and XBMC is selecting the wrong default one it seems. I think we got so focused on enhancing the remuxer to drop these audio tracks for live TV that I didnt really think about the fact that completed recordings will still exhibit the issue, if the audio tracks are in such a way that XBMC picks an audio track that you don't consider the sensible default. We just direct XBMC to play the WTV file so we aren't in control of much at this point, just "play this file". I wonder if it's possible that XBMC's video player needs some enhancements when it comes to WTV files and these hearing impaired audio tracks. It's kind of strange through becase our identification of these streams discussed earlier in this thread is based off ffmpeg source code, which I thought XBMC uses ffmpeg. I guess it's possible that it knows they are hearing impaired tracks but just doesnt have the logic to not select this for playback by default (or have an option to guide audio track selection etc).
There is a workaround you could use for completed recordings - We do have a server option "remux all recordings to TS" which will remux even completed recordings. This was more a troubleshooting option, particularly when it seemed raspberry Pi's had trouble playing large WTV files, but it would also work in your case. Remuxing the completed recording to TS will again cause us to drop the undesired audio tracks and your playback should be OK. The downside may be that you can't skip/fast forward as much as quickly after playback, since the remuxed TS file isn't full size yet. I'd be interested in your experiences with that as for some it seems that the remux job finishes quite quickly and FF/skip isnt much impacted but for others it seems that even after waiting a while, they still cant seem to skip much into the future of the recording.
In response to the 2nd item, this looks like a problem introduced in build 1114 where the audio stream checking is too harsh and ends up dropping all audio streaams then failing with a "no audio streams found" error. Krusty already released build 1115 to fix this, so hopefully that will take care of your BBC One HD problem. Please try 1115 and let us know. If it doesn't work, you know the drill
Upload the test flie and we will check it out.This TV stuff is so different between countries/providers it really is very much like chasing your tail sometimes! I know everyone appreciates our efforts to help, and we appreciate your efforts to highlight your specific cases and provide test files for us to broaden the scope of situations we can handle
2014-01-20, 23:01
So I tried the latest build (1115) and it worked as you described (HD channels now play as expected and all with correct audio track selected). So Live TV now works
As for audio selection on the .wtv recordings: the remux to .ts option works for playback but it does not remux quickly enough to allow skipping forward from the start ( which is necessary where the end of the last program is on the recording and for adverts). So looks like I need to raise this in another place to look at the general playback of .wtv files...
As for audio selection on the .wtv recordings: the remux to .ts option works for playback but it does not remux quickly enough to allow skipping forward from the start ( which is necessary where the end of the last program is on the recording and for adverts). So looks like I need to raise this in another place to look at the general playback of .wtv files...
2014-01-21, 00:11
Yes... to confirm, if you play the WTV file through the normal XBMC Videos section, you have the same default audio track issue? If so then yeah, we need to lobby the main XBMC video player component to have some more options/logic when playing WTV files. If you have a small test file to provide on a bug report that would be useful i imagine. I would post in a development or help/support forum and ultimatley look to raise a bug on TRAC with the uploaded WTV sample and also a link to the discussion where we are talking about identifying the hearing impaired SAP (secondary audio program) channels so they can be removed (in our case) or not selected as default (in the case of a playback engine)
