New DNAS Monitor

[thinktink]

Try resizing the column headers to hide stuff you don't want/need to see. It should save everytime you (re)start it.

[thinktink]

All of the column headers on both the main window and the server details window are all re-sizable. It will remember the column widths you set on (re)start.

[Skoen]

Ok. And one more thing. A mute button for the warnings. I had the program running for a while, and suddenly the computer started making noises of its own

[thinktink]

Which noises? The ones that say the listener count went up/down or the warnings about a server being offline?

If you want to quell just the listener count announcements there's an option to do so in the configuration window.

[thinktink]

You can also temporarily tell the monitor to suppress warnings for servers that have gone down until it comes back up again by hitting this button:

[Skoen]

Yeah, but I would like a mute all button as well. I have checked the box you show in the first screenshot. And the server making the error was just having a burp, so I was getting three noises in less than 10 seconds. Warnings are fine, just not audible, so a mute button would be nice. Like: Disable all sounds.
Other than that, I must say it's an awesome software.

[thinktink]

K, will add the feature on the next release.

[Skoen]

Awesome, looking forward to the new release

[Bryon Stout]

Pretty cool. I wish you would develop one for OSX.

Wavestreaming.com also created a windows/osx desktop app similar to this.

[thinktink]

I have made solid progress on all suggestions except for the IRC, AIM stuff. There just isn't a spot for them on the current version of the v2 DNAS so I don't want to invest a bunch of code for stuff that's obsolete.

[DrO]

as a note about the IRC/AIM stuff, if the v2 DNAS is provided it by the source then it will be available to be queried / shown on the stream summary pages / is passed onto the YP (if working that way though it's not used). depending on how you're pulling things from the DNAS will determine how easy it'll be especially when the /statistics option is made available (consolidated response of all /stats for active streams - which is in the internal builds you were testing and will output IRC, AIM and ICQ values).

-daz

[thinktink]

Originally Posted by DrO

as a note about the IRC/AIM stuff, if the v2 DNAS is provided it by the source then it will be available to be queried / shown on the stream summary pages / is passed onto the YP (if working that way though it's not used). depending on how you're pulling things from the DNAS will determine how easy it'll be especially when the /statistics option is made available (consolidated response of all /stats for active streams - which is in the internal builds you were testing and will output IRC, AIM and ICQ values).

-daz

Hmm, looks like I was wrong and have something to play with later...

[DrO]

on the site it's completely ignored from being displayed, but in the tools it's still there - am assuming from when the v2 DNAS was initially being written and it needed to support the v1 style of things.

obviously you don't have to do it but thought i'd better clarify that point.

-daz

[thinktink]

New v1.4 DNAS monitor available. Thanks again DrO.

[thinktink]

The Transcoder doesn't seem to be passing (at least the latest build) those old IRC/AIM/ICQ fields to the DNAS even when connected to it via v1 DJ port. The only time I can see those fields in the stats/pages is when I have the DSP directly connected to the DNAS in v1 mode. That's a very narrow set of circumstances to code for.

[DrO]

that's only because sc_trans isn't passing that information on at the moment - is one of the common requests from the last few months with regards to wanted sc_trans updates (is quite a few threads / posts which have been made about it ).


personally i don't think it's worth it as people have used it as a hackish way to determine the DJ in use and probably things should be done in a more formal manner in the tools but then that involves getting people to use the newer tools to be able to use it.

for example, sc_trans or dsp_sc could send the user-name in the metadata sent or leverage the username provided in the connection to the DNAS / sc_trans's DJ handling, but then that requires doing other changes later down the line to ensure that it is available to be queried from the DNAS.

so sadly at the moment it seems like keeping with the old aim/irc/icq usage is the simplest way to not break too much in order to get people onto the newer versions of the tools.


then again, maybe i should just go ahead and implement and if it is used or not then it's down to users and not something which is waiting to be implemented in the tools as i'm not in favour of re-enabling the IRC/AIM/ICQ options in dsp_sc as is when it's in v2 mode, so maybe the use of the DJ name is going to better overall...

[edit]
note a load of edits to my original post

-daz

[thinktink]

Originally Posted by DrO

[edit]
note a load of edits to my original post

-daz

I noticed. lol


Whichever way you decide to roll won't bother me. If you do do it I'll will grab them.

[Skoen]

Weird thing. I got like 10 000 instances running of DNASMON.exe in task manager, and I can't remove anyone of them.
Just installed the latest version.

[thinktink]

Lemme guess, you're on Windows 7 64 bit right?

Reboot the computer. Uninstall the old version then install the new one.

[DrO]

Originally Posted by thinktink

Whichever way you decide to roll won't bother me. If you do do it I'll will grab them.

Thoughts on it all since last night as something more formal in the long run i hope is going to be better...


If IRC/AIM/ICQ is provided by the source then that will be passed through (subject to source support so sc_trans will be updated to support this but not dsp_sc).


If connecting in v2 mode to a newer v2 DNAS, if a 'DJ / User ID' is specified then that will be made available in the stats able to be reported for the stream (still do decide on the name).


If connecting in v2 mode as a DJ to a newer sc_trans which then connects to a newer v2 DNAS, the DJ name from the calendar event will be passed onto the v2 DNAS as part of the metadata update (probably as a <V2DJ/> field) which the newer v2 DNAS will then be reported for the stream.

By allowing it to also be specified via the in-stream metadata means it can be updated once a connection happens (coping with DJ -> sc_trans -> sc_serv connections) but also if an older source is going to be used, it will allow for the DJ / User to be changed via the manual update (updinfo) commands. That way if a legacy v1 source is still going to be used, it's still viable to use the newer feature (though going native with updated v2 sources is going to be a better way imho).


Seem ok / not going to cause too many issues?
-daz

[thinktink]

I can't think of anything wrong with it.

[Bryon Stout]

Possible Mac app in the future?

[thinktink]

Sorry, I'm not a Mac writer and I don't think I want to run my head through a brick wall trying to port a Borland VCL front-end packaged application to a new native platform I have no clue about.

See if you can find a decent Windows emulator for Mac. It should theoretically run just fine in one.

[ram130]

Any updates or working links?

[thinktink]

Yikes! Didn't see your reply 'till just now. Latest version attached. Enjoy.

I would also like to direct you to have a look at Radio Toolbox v2 just in case it has more features you want than my monitor provides.
http://forums.winamp.com/showthread.php?t=344393