Internet Radio Listeners Field?

[mikeygduv]

Hey I'm new to WACUP. Long time Winamp user. Mainly use it as a Shoutcast player. I noticed in WACUP the internet radio shows many fields but is "missing" a listeners field.
Personally I used that as a way to browse channels rather than having to slog through each one. No idea if this is possible with the current setup but it'd be cool if that was added!

Update: after looking in the options I see there are refresh intervals of days and weeks so I see that a listener tab would not work with the current build. I'm new to coding but am curious what types of challenges there would be to have it work in "real time" vs being a saved repository?

[dro]

I don't show the listener count since not all of the services that I'm aggregating provide it (nor can they be relied upon when it is provided) & with it being a cached copy it makes it somewhat irrelevant to provide.

I went for a cached solution since doing it on the user's machine was basically using up too much resources (network bandwidth & CPU) & was taking a very long time to complete which often wouldn't if the user only listened to a few things which often meant it never completed updating & that's before getting into the crash reports that stemmed from it. So a single pull & then everything else grabbing that update is overall just quicker & more efficient imho.

Being cached has the downside of it only being relevant near the time of update though a lot of streams either are always there so it's less of an issue or they are super transient & often can be missed in 'live' updates. Sure having it live update would be nice though none of the services are themselves truly live to begin with & it's often suggested to cache things & then offer it to the user as that also helps keep the server loads down for them. I've thought about maybe upping the frequency of the cache update generation but as no one has really commented on it (I don't have stats to know what's being used or not as I just don't want to be collecting such data) I've assumed what I'm offering is ok for those that might use it.

-dro

[Aminifu]

...
I've thought about maybe upping the frequency of the cache update generation but as no one has really commented on it (I don't have stats to know what's being used or not as I just don't want to be collecting such data) I've assumed what I'm offering is ok for those that might use it.

-dro

This is somewhat related to the questions I recently asked in the General Discussion section. I don't listen to Internet Radio every day, but I have the internet radio update interval option set to daily. This way, if I'm understanding things correctly, every time I open the Internet Radio view in the Media Library the cache is automatically updated. I also think the "Last Seen" column provides more useful info than an inaccurate number of listeners column. However 6 genre columns may a bit of an overkill. 2 or 3 sub-genres should be enough, imo.

[dro]

With the updating it'll do it as per the prefs but there is a reliance upon the view being used. The reasoning was that if you're not actively going to it then it doesn't make much sense to keep updating the cache if it's not going to be touched but when it is then used then it'll update accordingly.

With the genres, I'm just going with what's provided across the different services & I agree it's too much but from the broadcaster view point they always want more (as it's a means of getting listed in things that don't relate in a lot of cases). I keep wondering about what is a better way to try to display the items but it'll have to stay as the basic list/column approach as things I've thought about either involve custom drawn items (bit like the mini artwork view mode in the local library) or there isn't the data easily available to make for a nicer looking entry.

-dro

[Aminifu]

...
With the genres, I'm just going with what's provided across the different services & I agree it's too much but from the broadcaster view point they always want more (as it's a means of getting listed in things that don't relate in a lot of cases).
...
-dro

Ok, I had already adjusted the view's column widths so that only the Genre2, Genre3 and Genre4 columns are visible. I was thinking that removing the extra sub-genre columns would leave room for adding other info. But I have no idea what this other info could be.

[dro]

I suppose I could just hide the genre columns & leave them as part of tooltip (with the tooltip as the whole displayed item being what I was maybe thinking about) as it's possible redundant with the genre tree to the side.

Other info is a big problem as there's no consistency in what comes from the api providers & the only other option would be to do manual scraping of things & trying to combine that into the cached data but that is also inconsistent / not viable from when I had to do that with the SHOUTcast listings (that was a wasted 5 months of my life doing that task!). As it'd be nice to show an associated website & a stream logo but that just isn't reliably found.

-dro

[mikeygduv]

That all makes total sense. The viewer count really just replaced a rating system for me. From a utilitarian standpoint I agree that what you gain is not worth the resources/effort to accommodate such a stat. Thanks for the info! I'm really enjoying the software so far.

[Aminifu]

I suppose I could just hide the genre columns & leave them as part of tooltip (with the tooltip as the whole displayed item being what I was maybe thinking about) as it's possible redundant with the genre tree to the side.
...
-dro

Putting the sub-genres in the tooltip is 1 way of dealing with things, but I don't think it is necessary. Since there is nothing that would replace these columns and you have not received complaints, then I think things should be left as they are. My solution (hiding the last 2 sub-genre columns and widening a couple of the remaining columns) works for me.

[dro]

The genres are already in the tooltip for the items though I did that mostly for accessibility. I think it's mostly that I'm not happy with a bunch of columns but it's what to do to show it in a more visually appealing manner without being a pain to code / maintain & that would be better for users. Like you say you can at least hide things

-dro

[Aminifu]

To be honest, I stopped trying to read the tooltips because they disappear before I can read all the info in those that contain a lot of genres and long URLs. Is it simple to have the tooltip remain as long as the station name is being pointed at?

[dro]

It can be done but I've not really messed with native tooltips derived from listviews in a long time it then might become a bit odd trying to adjust the behaviour. The timeouts are generally those defined by the OS though I can't remember if it's viable to override it (would assume it can but don't hold me to that ).

-dro

[Aminifu]

... The timeouts are generally those defined by the OS though I can't remember if it's viable to override it (would assume it can but don't hold me to that ).

-dro

Yes, your reply reminded me about some research I did in May, 2019 for the Winamp forum. Using the OS to increase the tooltip display time would also require increasing the mouse double-click time. This is not something I want to do, so forget about my request. If I want to read a wordy tooltip, I can just re-point to a station name repeatedly until I have read all the info in it's tooltip.

Tooltip Timing Info:

Three timing options associated with tooltips are controlled by the Windows OS and are related to your mouse double-click time setting. While it is possible for an app to override these global OS settings, I know of no app that does (or provides a user the option to do so).

The "TTDT_INITIAL" parameter (time a pointer must remain stationary within a tooltip's bounding rectangle before the tooltip window appears) is equal to the "GetDoubleClickTime()". The typical (default) double-click time is 500 ms (half a second).

The "TTDT_AUTOPOP" parameter (time a tooltip window remains visible if the pointer is stationary within a tooltip's bounding rectangle) is equal to the "GetDoubleClickTime()" * 10.

The "TTDT_RESHOW" parameter (time it takes for subsequent tooltip windows to appear as the pointer moves from one tooltip bounding rectangle to another) is equal to the "GetDoubleClickTime()" / 5.