View Single Post
Old 4th April 2012, 14:55   #17
Junior Member
Join Date: Mar 2012
Posts: 42
RayLine NSV Streamer 1.1.1 has been Released!

This version will hopefully fix any additional bugs found in the new IceCast Streaming Code along with a few other minor problems related to NSVx, among other things. Anyhow, on with the fixes:

(IceCast Support) Bitrate has to be reported on Source Connection in order for IceCast to Correctly Register in the "IceCast Stream Directory."

A new char of "-" have been added for the Name Description and Genre Field Filters.

A new char of "&" has been added for the URL Field Filter.

NSVx written by Ken used the "NSVs" Header as a Frame Tag (along with the real Frame Tag). This is a "NSV Container" Sync Header and has nothing to do with detecting physical frames. This caused an overcounting of frames which would periodically cause viewers to rebuffer because the stream was running slightly slower than normal. This issue will be fixed in the upcoming NSVx Version 0.1.3.

NSVx is able to gather user stats from IceCast now and will be included in NSVx Version 0.1.3. This support will allow RayLine NSV Streamer to display certain information on the program itself as well as in the HTML Guide. This was already supported on the Shoutcast side, except that IceCast doesn't report average listen time. So this variable will always reflect "0m 0s" when using it in the HTML Guide or while looking at the stats from inside RayLine NSV Streamer.

Fixed some of the Tooltips and labels so they don't say "Shoutcast" as the program maybe used with IceCast as well (I didn't realize how many times I wrote Shoutcast in the program until now). Even some of the program variables still have shoutcast in them (ShoutcastAddress, ShoutcastPort, etc), I guess I will leave them that way for now.

You can once again Save Playlist and Save Project while streaming (Provided you've already saved them once or opened one at some point).

NSVx now has a Error Handler Callback that can be used to Report NSVx Specific Failures to me. This feature will be available in the Version 0.1.3 of NSVx.

An Internal Debug System has been implemented in RayLine NSV Streamer for core functions. This will help people report unexpected bugs to our Forums.

Overflowing the Log Window causes the Log Window to Clear (Hopefully fixes an Overflow Issue).

Overflow in NSVx Frame Time Tracking Code (Rare, but could happen). This patch will be included in the latest coming version of NSVx 0.1.3.

Peak Listeners Stat Added to NSVx and RayLine NSV Streamer. This patch will be included in the latest coming version of NSVx 0.1.3.

I've been aware for a few versions now that there is a "Overflow" that occurs in the program on a pretty rare basis. I have had tons of difficulty trying to track down this issue. But after a lot of code study and seeing the problem happen a few times now, I have two ideas about what could be happening:

The Log Window is filling up causing an overflow. This has been fixed by placing an Error Handler in the AddLogEntry() Function to Clear the Log on the Log Window Full Error.

The StreamVideo() Function inside NSVx. The timeGetTime Function as provided by winmm.dll (Windows Multimedia Library) could be overflowing the variable in the program (due to my own oversight). I use this Function to calculate the next Frame Block Interval by incrementing it by 1 second (1000 ms). Documentation says that timeGetTime resets after 2,147,484 Seconds ( 2,147,483,647ms) (About 25 days, hints the fix in another version where the Feeder gets stuck. When timeGetTime Overflows, an IF Statement sees that and resets the Tracking Variable as well which fixes the 25day hang problem). This leaves from 2,147,483,648ms to 2,147,484,647ms open for Overflow because the Time Tracking Variable gets 1 Second (1000ms) added after each 1 Second Shoutcast/IceCast Video Burst. To fix this problem I've added another IF Statement that will check the Time Tracking Variable and if its Larger than 2,147,482,647 then it will be reset to 2,147,483,648 instead of adding 1000 causing the Overflow. The side effect will be that 1 second worth of frames will send early once every 25 days (no big deal, so it got slightly ahead).

Hopefully, I've fixed any remaining "Win the Lottery" crashes that could occur. I have placed debugger routines around critical functions (the list grows daily) to help give people the proper information that I need in order to easily fix an issue. I didn't mean for it to take so long to track down this problem but I've only seen it occur in a "Production Environment". I've never had this problem occur during Development or I would have fixed it on the spot 4-5 versions ago.

Last edited by pumbaa2; 4th April 2012 at 14:56. Reason: Forgot bold face
pumbaa2 is offline   Reply With Quote