A friend of mine sent me this screen shot. All I can really do is show a blank screen shot as I don't really have any NSV Files on my drives (just the ones I use to test the program with). But this clearly shows the "Schedule" of what is to come.

Yeah, I use it because it does provide a really stable stream at the correct bitrate without having to do the math and further take apart the NSV file to see how fast I should be streaming the file. The control is also pretty light weight and uses a very minimal amount of CPU time. My ONLY complaint is the lack of call backs from the control. Like progress, the control itself will display position but won't return a value or something that tells my program what position the stream it at allowing me to implement my own progress bar. So I left the control visible. So far it has also done what I've told it to do. My program has ran for days without any issues from that control. But I do tend to disconnect from the server and reconnect, etc when I need access to it.

Never used a YouTube playlist actually. The idea was to plot out a timeline of what is to come and when. That way the information could be exported to a HTML Page or XML. This would easily allow a broadcaster to display their schedule on their website. I'm still deciding on whether I want to make it "schedule slot" based. That way certain hours would always display certain programming with "commercials" for the filler. I quote commercials because it could be anything, music videos, funny clips from "The Man Show" or "In Living Colour", etc, etc. Actually running commercials and not getting paid for them would be stupid, but there are many things that could fill the gap between programs to keep the scheduler "on track."

Feel free to check the website for more information about this project. On top of the features mentioned above, I've added HTML Guide Generation. This will allow servers that are using this program to create a "TV Station" to update their website with what is going to come on and when. For the moment, times are posted according to the local time on the server itself. If you want to see an example of the HTML Guide, a friend of mine is running it on his website. You can look at the guide directly by following this link: http://thepiratesden.dyndns*****Piratetv/channel1.html

This Guide is LIVE (not a demo). It updates at regular intervals. The channel name at the top should show up in the Shoutcast TV Directory. If you have any questions, feel free to post here or on my Forums.

Fixed Bug: NSVx would fail to reset progress to 0 and report the event on "Stop Stream."
NSVx Control has been moved to the Configuration Page as Progress is reported by NSVx Events now, but not hidden as a Thank You for Ken's hard work.

I will likely not release NSVx.ocx Version 0.1.3 until version 1.0.8 of RayLine NSV Streamer. Many of the new enhancements need testing to ensure functionality. The User and Averages information works with Shoutcast Version 1.9.x but I really wouldn't mind if someone tested it with 2.x. There are code parsing trappers to prevent errors in NSVx.OCX but the result will be no triggered update events if there is a problem gathering User and Averages Information (which would result in users staying at 0 and Avg Time staying at 0m 0s).

There are also some more timing issues that have to be resolved in relation to stream parsing for "Frame Tags". There is the likelihood that the NSVx Control may miss a frame tag causing it to under-count the number of frames being send out (25fps but 26 or 27 frames gets sent by mistake). This would result in the Control getting slightly ahead of itself and possibly causing a overrun in the Shoutcast Server. The timing issue is minor compared to the one I fixed and the result may cause a pink block here and there but nothing critical. The particular problem requires a rewrite of the stream parsing routine which may result in a rewrite of the streaming code itself. The stream is also pushed in 1 second intervals (all 15 frames at once for 15fps or 30 frames at once for 30fps) and and could cause Shoutcast Server overruns especially at extremely high bitrates (Generally, HD Video 720p or Higher) which could result in corrupt video. The ideal situation is to push the video one frame at a time however this may increase CPU Time used by NSVx. With today's processors, this should be a marginal impact but I will be performing testing before implementing the changes.

Due to an issue with NSVx leaving files open and allocating new file pointers until all resources are exhausted, it was interfering with my programs ability to open files. This problem wasn't really noticeable before because NSVx was being used as a separate component, but as its apart of my streamer now it really got in the way of my file allocators. To fix this problem I have issed an emergency release as version 1.0.8RC1 to fix this MAJOR bug. The issue of files being left open after stop stream has been issued to NSVx will be patched as well in the new coming version of NSVx 0.1.3.

This release handles various bugs that have crept up during the process of making this program. I've spent most of my time writing new features that I needed to slow down just a little to address the little things that go wrong. The following bugs should be fixed now with several GUI Enhancements:

HTML Guide doesn't set the font color which can clash with some windows themes causing the text color to be the same as the table color.

The infamous timer overflow in NSVx causing a stream to get stuck indefinitely in the "Wait to Send Next Video Frame State" once every 25 days has been fixed (Will be included in NSVx Version 0.1.3).

Additional Variables have been added to the HTML Guide to better customize the experience.
Offline HTML Guide page wasn't being generated on Exit (while still streaming), leaving viewers believing the station was still online.

Selecting a HTML Guide Template and then cancelling the open dialog would clear the previous template instead of keeping it.

Output HTML Guide "Save As Dialog" would fail to append ".html" to the file name if the file extension wasn't already specified (Valid extensions are *.html, *.htm, *.txt and *.php).
NSVx AND RayLine NSV Streamer tend to create 0 byte files if either attempt to open a NSV that don't exist because of the "Default Binary Read-Write Mode." NSV's should be opened as read-only. (Will be included in NSVx Version 0.1.3 with a new "State Condition" of "File not Found" for this problem, handle as if it's back to State 1).

Failure to run NSVx.Setup (AND NSVx.Header if you're using Ken's Version 0.1.2 Spec) before NSVx.Connect will stay at State 0 causing a infinite loop in your program if you go by the Programming Instructions in the Demo Program (Written by Ken). Since all programs use this loop that I've seen so far, a new "State Condition" will be created that means, "Please Setup First". However, the correct way to handle this would be the same as Winsock itself, Raise an Event when the Control is ready for Streaming, not a "While NSVx.State = 0: DoEvents: Wend". This causes 100% CPU during the "Shoutcast Connect" and isn't necessary (granted a sleep call could be added but that isn't the point). This is a NSVx Specific issue and is still being worked on.

A default interval of 10 minutes (which is adjustable or can be disabled) has been added to recreating the HTML Guide. Useful for updating stats on the Guide like "Users Connected to the Stream" and "Connection Averages" on a more regular basis.

Ability to New Project, Open Project, New Playlist, Open Playlist and the ability to adjust the Shoutcast Server Settings while streaming is now disabled! Taking these actions while streaming is asking for a crash and if everything does survive, it will very likely cause very unexpected results. Any config options that are still supported while streaming will stay enabled. You can still add files and delete files from the current playlist while streaming.

You can no longer move a file down past a blank line. This wasn't fatal and would just cause the streamer to "Finish" at the blank line as if the playlist is over. It was still confusing and only LostChain (in his infamous efforts to BREAK MY PROGRAM) would attempt to do something like this to prove a point. FIXED!

Status Bar to give more detailed information about what is going on.

Experimental Drag/Drop Support for File Fields in HTML Guide Configuration.

Experimental Drag/Drop Support for NSV Files on to "Add Video to Schedule" Button (Button is always enabled now for Drag/Drop Reasons).

Field Tab Order has been fixed.

Auto Reconnect to Shoutcast (30 Second Timer and same rules as Winamp's Shoutcast DSP with the exception of restarting the current Program).

IMMEDIATE Minimize on Startup (If Enabled).

IMMEDIATE Connect on Startup (If Enabled).

Experimental Drag/Drop of Playlist Items using Single or Multi-Select Options.

This release handles various bugs that have crept up during the process of making this program (part 2). The following bugs should be fixed now with several GUI Enhancements:

Multi-Select Insert on Playlist items works correctly when moving items that are "earlier" in the list because the list shifts down as the items are pulled out. But when taking items from "after" the insertion point causes the list to be shifted up which makes playlist items order backwards during insert because the insert pointer is static.

The Public Server Setting was being ignored which always told the server that it was a public server causing it to be listed in the Shoutcast Directory.

The Public Server Setting wasn't being Saved in the Project File (Default Public Server Setting is "Enabled").

Selecting "Auto Save on Rotate" and streaming a new project that has never been saved before causes a "Save As" Dialog to appear on Playlist Rotate causing the streamer to hang until the project is saved or the dialog is cancelled.

Moving or Deleting a NSV File in the playlist will cause the streamer to create a 0 byte file when the file is opened. It seems that "Open Binary Access Read" doesn't throw an exception when the file is not found. The file will now rotate and turn red or roll off depending on settings.

Moving or Deleting a NSV File after the playlist is loaded creates a 0 byte file when it comes up to be streamed (NSVx should handle this correctly by returning a "File not Found" error code). This was supposed to be fixed in 1.0.8 but I was having some issues with it.
Dead Entries will roll like the the good files now but still won't show up in the HTML Guide. Its better to discover something is wrong, then it to silently disappear and never get noticed.

Internal NSVx Support for "Reconnect to Shoutcast." This will allow the stream to pickup from where it left off (if the connection can be re-established immediately). Otherwise the 30 second timer will restart the stream. This support will be available in NSVx Version 0.1.3. The NSVx Progress Bar will turn Red momentary to indicate that it lost connection and is trying to reconnect.

You can move a file out of position 1 while streaming using the old style movement keys. This causes unexpected results and should be disabled or the file being placed in position 1 should start streaming right away and the old stream should be aborted.

Multi-Select files can rotate into Position 1 allowing it to ultimately be moved while streaming. Files that roll into Position 1 should be un-tagged.

Pressing the X Box to Delete a Program Entry would fail to move the selection with the file as the list drops causing the wrong item to be selected.

Time/Date's were being displayed for non-existent playlist items (Would display incorrect values now that Calculate Schedule Times skips over slots without programs in them).

Much better optimization for "Calculating Schedule Times" greatly increases the Refresh Rate of the Page after files are added or deleted.

Item 1 is Greyed out during streaming to indicate that slot can't be messed with (Except the "X Box" which obviously skips the stream item and rotates it if enabled and deletes if not enabled).

Hopefully at this point, I've caught all the major problems with the program. I've done some extensive testing with the program and I'm pretty sure I've covered all the problems that could result in a program crash. The UI enhancements should make playlist manipulation easier than ever!

Native IceCast Support! This is great stuff as there are many benefits to using Icecast. Granted Icecast does support Shoutcast "Compatibility Mode" but it is very limited on how many streams you can have or the functionality and manipulation of the stream options... now the Fixes:

Native IceCast 2 Support!

Program fails to show up if Auto-Start is enabled and the program is started from the project file.

Multi-Select release in an invalid field doesn't reset the colors of the Prev/Next Buttons.

Strict Filtering of Fields prevents errors that could cause problems with the program or server.

Auto show password on field highlight makes password mistakes less of a headache.

Minimize on Auto-Start will Minimize of Load regardless if Auto-Start is enabled or not.

I wrote the IceCast handling routines directly into NSVx and will be available to anyone who wants to use native IceCast support in their programs via NSVx. People who have already written programs based around Ken's NSVx Version 0.1.1 or 0.1.2 will only have to make minor code changes to implement the IceCast Support in their program. This support will be fully released in the upcoming NSVx Version 0.1.3 for anyone who wants to take advantage of this support. Currently the client doesn't update user stats from the IceCast Server but I will make sure to correct that in the upcoming Version 1.1.1.

Please Note: Due to limitations that I wrote in the initial "Project File" format, I've had to upgrade the format. This shouldn't be a problem as I've written an auto up-grader in the program to re-write your Project File using the new format. All settings and playlist information will be preserved, but keep in mind that once you upgrade your "Project File", you can no longer use it with a version of RayLine NSV Streamer below 1.1.0. However, if it is really necessary to use it again with an older version of RayLine NSV Streamer, you can load it but it will have some invalid "files" at the beginning of the playlist. Simply remove the "Invalid" files and re-save the Project File. But if you have any doubt in your mind, you should make a backup copy of your "Project File" first before doing the upgrade. The program will ask on Project Load if you want to upgrade your Project File and you have the option to refuse, just be aware that if at any point you press "Save Project" or it "Saves on Rotate", it will silently upgrade the project file.

Thank you! Now if the Operators over on the IceCast Forums would ever approve my account, I could post this update over there as well. This maybe something you may want to add to your nsvice page. I see you wonder over there as well and help out. I even found some PDF Documentation written by you on using IceCast. That was helpful in my implementation, but not as helpful as Wireshark I think the hardest part was figuring out that WWW Basic Authentication uses a Base64 encoding with "source" as the username when adding a Source to Icecast. Also, the internal metadata URL (not the backend webpage one) to post updates to IceCast took a little digging too. But now it works just as good as it does with Shoutcast.

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.

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

We are still working on some minor bug fixes that have come up and were able to be fixed thanks to my Debugger that is now built into RayLine NSV Streamer.

Fixed an Overflow related to Winsock in NSVx causing a Debug Exception Window for Line Marker 8820 Error 6 (NSVx wasn't monitoring output buffers during transmit which could cause an overflow, rare but happens).

Debug Window failed to center itself and could come up off the screen.

Peak Users Variable added to HTML Guide (Forgot to add this in the last revision, oops).
Listen URL added to HTML Guide (Allows for a Listen Now option from the Guide itself).

NSVx.Connect while connected or connecting causes exception, now connect can be used as "Reconnect." Useful if you change certain Server Flags and need to update the server with the changes.

NSVx Bitrate Information for Icecast updated to use standardized 1024 block size. This also ensures that header tag receives only a number.

Hopefully, I've fixed all the alignment issues with NSVx when it comes to realtime streaming. If all goes well with this release, I will release the latest version of NSVx 0.1.3. I know a few of you have downloaded the old version 0.1.1 but this version will be much better and has better support. The API changes from 0.1.1 and 0.1.3 aren't that hard to adapt to (and even easier if you've used 0.1.2). For the most part, the NSVx control has the same functions, just more of them. It also has 3 callback events that will signal a subroutine in your program when the number of users on the server has changed, an exception has occurred, and for Percent Completed. A full demo program will be included with NSVx to demonstrate its capabilities.

Thank you! I feel real confident with this release. It takes so much time to develop a program and make it user friendly. I thought about backporting the changes for NSVx to make a 0.1.1 compliant NSVx Control that could be easily swapped out after installing one of the old clients. I'm hoping once I release 0.1.3 of NSVx a few developers of the older clients will jump on board and implement the changes. The control has come a long way and it isn't anymore resource hungry than it was originally. Infact, RayLine Streamer barely registers as using any CPU during streaming mode.

I'm still working out shuffle. People should be able to shuffle the list by clicking on an option and the list will rearrange itself in the new shuffle order. So there is two ways about doing this. The first one is a "predictable shuffle" by interweaving the list. The list is 40 items long so it would go kinda like a deck of cards. 19, 20, 18, 21, 17, 22, 16, 23, 15, 24, 14, 25.... The second method would use the random generator (Randomize Timer). 40 items in the list, generator picks a number, insert item 1, take item number out of the list and reset generator for a random number 1 to 39, insert item 2, reset generator for number between 1 and 38, insert item.... Item numbers already filled won't get counted when counting up the number of empty slots for the next song insert. The problem with this method is it will literally have to run a loop for however many items are on the list, except the last item which obviously gets inserted in the last blank slot. This method could be CPU time consuming during the randomize process where the other method is predictable and requires 1 loop with 2 variables, 1 counting up and another counting down, then alternate between them.

If you have any good ideas on a simple shuffle code, I'd love to see it. C++ or VB6 code is welcome. I am very good at writing code in both and can easily convert between them. To bad I didn't spend more time learning WxWidgets, it would be nice to make this program platform independent. I do know some QT though... I hear there are QT Libs for Windows now.

The problem with this method is it will literally have to run a loop for however many items are on the list, except the last item which obviously gets inserted in the last blank slot. This method could be CPU time consuming during the randomize process where the other method is predictable and requires 1 loop with 2 variables, 1 counting up and another counting down, then alternate between them.

Why pre-shuffle the whole "deck" - you aren't dealing cards - you're streaming media, one item at a time

have a pool of unplayed items ... dip into it randomly and remove an item when you want play something ... while playing, you don't care what's in the pool

that way ... you can add to the pool at any time ... pre-shuffling would require you to re-shuffle when adding to the list