gAlleb/sse_cf_demo.js

Interesting fact: The schedule shows station time but the red "pointer" (we are here) points to the correct playlist time. So even if it was already 10:00 your time, it shows 8:00 on the station. So at least the correct currently playing show is indicated!

I’m thinking of adding something like a np-server-time and maybe even some progress indicator to the script, how do you feel about that? Since (with HPNP enabled) we’re getting a time signal roughly every minute, and NP updates roughly every 10s, it might be nice to (separately) update an HH:MM server time and (per station) progress indicator, say a small white line at the bottom of the album cover……

We could use getTimeFromTimestamp(timestamp) to display the times, I’m thinking.

I introduced (but not yet published)

• np-global-time (coming from the AzuraCast timestamps)
• np-global-timezone-short, i.e. GMT+3
• np-global-timezone-long, i.e. Москва, стандартное время

Time is always user local time, timezones displayed in user’s browser language. Just in case.

We might want to ask @BusterNeece to include the station timezone (ex: Europe/Berlin) in the /nowplaying, /nowplaying/{station_id}, /stations and /station/{station_id} API endpoints, since they can be different from station to station (think resellers). With this, we could recalculate and either show listeners a time difference (schedule!) or at least state something like "Times shown are Central European Standard Time, GMT+1").

EDIT: Added a feature request.

Try https://grav1.niteradio.net/wh/sse_cf_demo.html to see if this works on your end so far.

On Linux, in a terminal, you can, for instance, use

TZ=Europe/Moscow chromium

to start up a browser in a timezone different from your own.

Hmm. Seems I can’t add a screenshot here anymore.

It's a great idea!

and (per station) progress indicator, say a small white line at the bottom of the album cover……

It sounds nice)

we could recalculate and either show listeners a time difference (schedule!)

Not sure what you mean here. We can change schedule page to accomodate listeners's local time? If so - it would be great but I can't imagine a way of doing this)

Yea, it works)

In mumbai))

That’s good to know, thanks for testing! Can you wait a little longer, maybe until we get the station timezone as per feature request, or should I publish the "intermediate" in my Gist?

We can change schedule page to accomodate listeners's local time?

No, unfortunately not. That would be something the AzuraCast dev’s must do (if they want). Since I included the schedule in an iframe in my page, I was thinking of at least showing the listeners something like "Times shown are (timezone info)" or "Times shown differ by +6 hours from your local time" or the like.

P.S.: In the browser console, you can already see the potential progress bar data (elapsed/duration in s).

Oh, I see.

Can you wait a little longer, maybe until we get the station timezone as per feature request, or should I publish the "intermediate" in my Gist?

As it suits you :) I can wait

First version with a mini progress bar, as yet unstyled.

Oh, Looks nice!

Been thinking how to show Times shown are (timezone info)" or "Times shown differ by +6 hours from your local time until we got the feature.

Came up with something like (dirty)

function tz_difference() {
      //Getting local listener time
      const date = new Date();
      // Getting Timezone offset in minutes
      let tz_difference= date.getTimezoneOffset();
      // Since I have UTC+3 = plus 180 minutes
      let my_tz_difference = Math.floor(tz_difference+180);
     // Divide by 60 :) but it eliminates “minus”))
      document.getElementById('time_difference').innerHTML = Math.floor(my_tz_difference/60);
    }

Yeah, but if we don’t hardcode our station timezone, we’ll never know the difference to the schedule :-(

I love unobtrusive: Look again (maybe zoom) at the lower edge of the album art. You can also try to hover over the little bar. ;-)
It’s astonishing that all browsers haven’t gotten their progress color right, grr. accent-color only works when you don’t remove the border.

I give you an np-station-song-progress to be used on a <progress> element, which fills in value, max and title. It can be put anywhere and styled as you want. What do you think?

Looks great! It is very neat!

Regarding time zone. Nothing to be hardcoded here cause getTimezoneOffset always returns difference between UTC+0 and your local time. In order to get difference between station time and listeners time we only need to add or subtract the difference between UTC+0 and our station.

Nope, you are right. However wait, let me think. No, I am right. Everything works. Started questioning myself for a second.

Everything makes sense:

getTimezoneOffset always returns difference between UTC+0 and your local time. In order to get difference between station time and listeners time we only need to add or subtract the difference between UTC+0 (getTimezoneOffset) and our station.

e.g. your station is UTC+1. getTimezoneOffset + 60 is your hardcoded difference. It will return 0 for you. It will return -120 for me because for me getTimeOffset is -180 plus 60 equals -120. If I am in New York it will return 360 (UTC-5 for New York + 60 minutes of your station difference against UTC-0).

But we still don’t know the station’s real timezone, right? Because we don’t get it from AzuraCast.
And I don’t get <progress> and positioning to work correctly on older Android phones… darn.

Looks like I got it… Do you—by chance—have a few different OS’es, Browsers, Android and iOS devices ready? So we could test if this page gives correct progress bars on all devices/browsers?

I switched one testing station to Moscow time, could you please check its schedule?

Oh, and are you on the Discord so we could test some things more privately?

I switched one testing station to Moscow time, could you please check its schedule?

Yeap. Shows correctly.

On iOS works fine:

On Windows and MacOS too:) Sorry) Couldn't wait)

Also wrote such function. Works well:)

    function tz_difference() {
      const date = new Date();
      let tz_difference= date.getTimezoneOffset();
      let my_tz_difference = (tz_difference+180)/60;
      if (my_tz_difference < 0) {
      document.getElementById('time_difference').innerHTML ="Time shown is Europe/Moscow timezone (UTC+3). Times shown differs by −" + (my_tz_difference*-1) + " hours from your local time."; 
      }
      else if (my_tz_difference > 0){
      document.getElementById('time_difference').innerHTML ="Time shown is Europe/Moscow timezone (UTC+3). Times shown differs by +" + my_tz_difference + " hours from your local time.";
      }
      else {document.getElementById('time_difference').innerHTML = "Time shown is Europe/Moscow timezone (UTC+3).";
      }
    }

When in Moscow - doesn't tell about the difference of timezones:

Shows great as well!

Sometimes API fails and bar is always full until next track. Hm)

Sent a request in discord.

on iOS works well

Sometimes API fails and bar is always full until next track. Hm)

Yeah, that’s the "metadata sometimes missing" bug in AzuraCast. Thanks for testing! Unfortunately, GH won’t let me click on the images, shows blank page with "private user image". Anyway, seen enough ;-)

Great job with progress bar! Thanks!

Well, "together" is always better! :-) Guess I’ll put the new code in the Gist tomorrow.

Yeah, great idea! I'm already using it and loving it ;)

Looked at your tz_difference. Unfortunately, this will only work in countries where the UTC offset is fixed (i.e., Russia, since I believe you’ve gotten rid of daylight savings time switching). For all other cases (like Germany), where the UTC offset can actually vary (UTC+01:00 normal time, and UTC+02:00 daylight savings time here), simply using a fixed offset will fail. It must actually be found out for every current date & time, because we might just be on the boundary of switching to DST, or vice-versa.

We could use moment or Luxon libraries for this but I don’t want to introduce extra dependencies here. Too bad Javascript doesn’t store the timezone in the Date object—that really sucks.

Let me think of something…

Thanks @Moonbase59 ! Yeah, we should wait for the feature request. I have read about it yesterday and looked into moment with bunch of different js and years they contain:)

Like the progress bar) Since I've accomodated the progress bar at the bottom of screen and fullsize - it seams a bit odd when it is progressing with big chunks every 10 seconds. I've thought of a way to make it faster. Could you look into it and maybe propose some changes to polish it.

1. I've moved setElement("np-" + ch + "-song-progress" to be updated only when Song Hash ID changes (like the rest of elements)
2. Added this code. So it takes "elapsed" and adds 1 second to it every second until Song ID Changes and it starts over:

    setElement("np-" + ch + "-song-progress", null, {
      attrib: {
        "max":  np.now_playing.duration,
        "title": "Total Duration: " + minSec(np.now_playing.duration) + " | Don't click! You'll achieve nothing by that:)"
    }});

    const track_update_interval = setInterval(updateProgress, 1000);
    
    var elapsed  = np.now_playing.elapsed; 

    function updateProgress() {
      elapsed  +=1; // add time every second
      setElement("np-" + ch + "-song-progress", null, {
        attrib: {
          "value": elapsed,
      }});
          if (np && (np.now_playing.sh_id  !== subs[station]["last_sh_id"])) {  
          clearInterval(track_update_interval);
          }
      };

Works quiet fine as far as I can see.

I didn’t check Buster’s code but he must be doing something like that in the official player, too. Maybe I should play with it… only it is included in almost every page of my website, so I fear the overhead a little. (Just because I’m lazy. So for instance, if someone changes the station description or name or such, it will automatically reflect on my website. Or if links change.)

Nice idea, in any case. Looks real smooth! Do you check for value exceeding max? Don’t know if all browsers would handle that gracefully.

Btw, I still like moment a lot, but it’s gotten a bit rusty, and most devs (like Buster) prefer Luxon nowadays. Luxon, as far as I know, is also used within AzuraCast.

Did you check out my latest update already? Introduces new station time stuff which should work everywhere on the world. ;-)

Did you check out my latest update already? Introduces new station time stuff which should work everywhere on the world. ;-)

Just checked. For me it retuns UTC+0 time as station time (and my station is UTC+3). Tried to pastte "niteradio" main url in my script tto show your station time for test - it shows again UTC+0 (But should UTC+1)

UPD. Oh silly of me! I have to edit "station:radio": {timezone: "Etc/UTC"}," ) to Etc/GMT-3 :)

Works great! Thanks @Moonbase59 !

(Just because I’m lazy. So for instance, if someone changes the station description or name or such, it will automatically reflect on my website. Or if links change.)

I didn't get it)

I tried to say I fear "overloading" this with all the extras, because the script is on each of my webpages. And thus it uses resources. And the reason it is on all my (station) web pages is that I’m lazy. I don’t want to change things on my webpage when the script can deliver the same data directly from the AzuraCast server. (Like station names and descriptions, links, etc.)

The timezones for you and me should probably be Europe/Moscow and Europe/Berlin. That’s what I tested with. Just use the names from the IANA list. (So India would be Asia/Kolkata—good for testing because it has a half-hour offset.)

With "station:radio": {timezone: "Etc/UTC"} we specify the timezone per station (the same AzuraCast server can have many stations in different timezones). This will be replaced by data from the API, once we get it.

Yeah, Europe/Moscow works as well.

Do you check for value exceeding max? Don’t know if all browsers would handle that gracefully.

This must happen everytime when jingles play. But I haven’t noticed anything unusual yet.

The idea of self-updating "smooth" progress bars is actually nice. Thanks for the idea.

Your code will fail awfully if you have more than one station, though. I will smoothen it out a little and use the subscribers (subs) object to store elapsed, duration and the ID of the updateProgressBar interval.

Updates, as usual, on the live demo page, and in my Gist. The "Winterzeit ist Radiozeit" page on my website will show 5 stations updating in parallel (hopefully).

Sounds nice!

Your code will fail awfully if you have more than one station

I've tried with two stations. I think it worked well.

But I'm glad that you've decided to give it a try! I'm sure it would work better:)

Replied in discord.

Up & running! Could you test with your full-width progress bar, please?

Thanks! Tried updated code, it is smooth, works very nice. 👍 Changed "title": "Total Duration: " + minSec(subs[station]["duration"]) since when it is elapsed in there - it is flickering every second if you hover and it's kinda disturbing)

Thanks!