Posts: 3,438
Joined: Aug 2012
Reputation:
91
SoCal, I can't reproduce the problem with the no-video file you sent me. I ran it through the remuxer and it plays fine. Can you restart swmc so the log is clean, and then try to play one of these channels. After it fails post a link to the whole swmc log.
Posts: 1,378
Joined: Oct 2004
Reputation:
37
getting a 404 on the server log. pop it on pastebin if its not too large for their file size limit
Posts: 78
Joined: Sep 2013
Reputation:
3
Try it now, had to add .txt to get past the application pool settings... it was too big for pastebins 500k limit and I'm not a PRO account.
Posts: 78
Joined: Sep 2013
Reputation:
3
I uploaded about 6-7 files from that directory. I was surprised that all of them play in Windows Media Player.
Posts: 3,438
Joined: Aug 2012
Reputation:
91
I think I know why audio-only channels are not working. To see if I am on the right track, change this value in swmc's config.xml:
RemuxParseMaxHeadersForAudio change it from 2000 to 550. After saving, restart swmc and try to play one of your music channels.
Posts: 3,438
Joined: Aug 2012
Reputation:
91
2014-03-13, 00:52
(This post was last modified: 2014-03-13, 00:53 by krustyreturns.)
I still think I am right, I just picked the wrong value. The problem with audio only channels is we wait a long time waiting on a video stream, before we give up on video and assume audio only. That coupled with what seems to be a long wait for data after you tune to one of these channels is the problem. In the log you posted, this line:
2014/03/12 12:29:25.138 Parse> Descriptor pass done, using 393 guids in 8.05 sec
means that in 8s it had only read 393 guids (think data headers), external to this remux thread we are waiting for a start of the ts stream before we hand control back to xbmc, when that ts doesn't show up after 10s (default value) we assume something has gone wrong and kill the remux thread. That's why the line above is preceded by:
2014/03/12 12:29:25.127 StreamProc> process start error: Stream file 'ts' does not exist (likely no data was found to remux), timeout: 10,000 ms reached. calling Close()
I guessed having it stop looking for video after 550 headers would be enough, but by the time it timed out only 393 headers were reached (even though the audio stream was fully determined before that).
So to make it work you can increase the timeout time (Timeout_WaitForTS_MS), or further decrease the number of headers it searches before it gives up on video. To decrease the headers you have to change both RemuxParseMinHeadersForAudio and RemuxParseMaxHeadersForAudio (making sure the max value is always greater than the min value) Changing RemuxParseMinHeadersForAudio=200 and RemuxParseMaxHeadersForAudio=225 will probably do it (or double the timeout time) Whether it still works for your video channels at this setting you'll need to test.
Obviously this isn't the way to handle this, we need to think more about the best way to handle audio-only channels.
Posts: 3,438
Joined: Aug 2012
Reputation:
91
While you are messing with the config.xml file, temporarily set Debug_ChannelDetail to true. Then, after restarting swmc, post the server log again, I'm thinking that these channels could be flagged already as audio-only by wmc - in which case we won't need to spend any time looking for video.
Posts: 1,378
Joined: Oct 2004
Reputation:
37
2014-03-13, 02:39
(This post was last modified: 2014-03-13, 02:41 by scarecrow420.)
Sorry for being late to the party but just chiming in that I was also able to remux the test files fine and my thoughts were as you already said, that it was a timing issue where the remux was being cancelled before it got far enough. It's odd to see it took 8 seconds to process that many headers, I wonder if its because with no video data there, there just arent that many headers/packets in the stream. A smaller bitrate means less data which means it takes much longer to reach our "min/max headers" settings.
I do worry about having those values set so low, that you might start to encounter streams where we stop the descriptor pass before the video or audio tracks had been fully described but i guess you will just need to keep a look out for it for a while.
I agree with KR that ideally we need to know these are audio channels upfront, then we can handle things properly, by not looking for video streams during remux and possibly by even using the XBMC Radio channels for these ones, and not sending them through for the TV channels section anymore.
I will check out my audio channels at home and see if they "look" any different when they come across. Worst case I suppose, if we cant figure out the audio channels in an automated fashion, we could have a config file entry to define the callsigns/numbers that should be treated as Audio Only channels.
Posts: 3,438
Joined: Aug 2012
Reputation:
91
2014-03-13, 04:20
(This post was last modified: 2014-03-13, 04:21 by krustyreturns.)
Hey scarecrow, since you have audio-only channels take a look at the Channel object in epg.cs using the debugger. I found a field Channel.Service.ServiceType and the enum for service type is:
public const int Audio = 2;
public const int InteractiveTV = 3;
public const int IsdbBookmark = 4;
public const int IsdbEngineering = 5;
public const int TV = 1;
public const int Unknown = 0;
Maybe these channels are marked as Audio?
Good idea on the bitrate, that would explain it.
SoCal, if the reduced header counts are working for you on your normal channels I think you'll be fine. If occasionally you can't tune to a channel consider raising them a little.
Posts: 1,378
Joined: Oct 2004
Reputation:
37
2014-03-13, 14:25
(This post was last modified: 2014-03-13, 16:09 by scarecrow420.)
The audio channels on my system come up as ServiceType=2 (Audio) which is good news! Ive enhanced the channel logging to output this. I've made preliminary changes to better handle audio only channels in the remuxer with separate min/max header settings and higher thresholds to prevent warnings being logged etc. I haven't yet filtered the channels out of the normal channel list and instead send them to XBMC as Radio channels. Still tossing up whether to do that or not (will probably do it over the weekend and make it configurable whether to send them to Radio section or not)
