Author Topic: (Version 1.8) Spectrogram Panel Plugin  (Read 101939 times)

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
Well I give up on this.  Installed the 2017 re-dist and started over with a fresh copy of MB from my back-ups, no change, no PNG will draw.  Could be something as basic as "not compatible with Windows 7", or even my video drivers.  At any rate, maybe somebody else who is using Windows 7 can chime in if it's working for them.  Thanks anyway zkhcohen for the effort you have put into this, much appreciated.  I plan on updating to Windows 10 (and a new PC) anyway this year, so I'll revisit it then.

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
Well I give up on this.  Installed the 2017 re-dist and started over with a fresh copy of MB from my back-ups, no change, no PNG will draw.  Could be something as basic as "not compatible with Windows 7", or even my video drivers.  At any rate, maybe somebody else who is using Windows 7 can chime in if it's working for them.  Thanks anyway zkhcohen for the effort you have put into this, much appreciated.  I plan on updating to Windows 10 (and a new PC) anyway this year, so I'll revisit it then.

No problem! I'm sorry that it's not working.

If I get a chance, I'll try to spin up a Windows 7 image in a VM and troubleshoot it myself.

Hopefully other people will test it and report back about compatibility issues.

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
Well, blow me down, as Popeye used to say.  FOUND IT!  Found that you supply a 64-bit version of ffmpeg.exe with the plugin, which of course is not compatible with a 32-bit OS like poor me has.  Yours was the only copy I used in my tests.  Swapped it with my 32-bit version of ffmpeg 4.1.1, and there is the display!

Also tested the external path feature, I used "c:\ffmpeg\ffmpeg.exe" despite the note saying "use /ffmpeg in the path" (forward slash) and works just fine.

Default settings of Saturation=0 will show black & white for any color setting unless set to something other than "0"--which makes sense but maybe worth a note in the readme.

As expected, will display no image if a radio stream is played;  however, this also "hangs" ffmpeg.exe which then must be killed with Task Manager before the plugin can function again with an audio file, even upon MB exit.  Unfortunately, because I go back and forth between stations and files regularly, this sort of kills the usability for me.  Is there a way to tell it to ignore streams (not load ffmpeg)?

Man I love it when a plan comes together though.  The frequency legend is buff, BTW! 8)

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
Well, blow me down, as Popeye used to say.  FOUND IT!  Found that you supply a 64-bit version of ffmpeg.exe with the plugin, which of course is not compatible with a 32-bit OS like poor me has.  Yours was the only copy I used in my tests.  Swapped it with my 32-bit version of ffmpeg 4.1.1, and there is the display!

Also tested the external path feature, I used "c:\ffmpeg\ffmpeg.exe" despite the note saying "use /ffmpeg in the path" (forward slash) and works just fine.

Default settings of Saturation=0 will show black & white for any color setting unless set to something other than "0"--which makes sense but maybe worth a note in the readme.

As expected, will display no image if a radio stream is played;  however, this also "hangs" ffmpeg.exe which then must be killed with Task Manager before the plugin can function again with an audio file, even upon MB exit.  Unfortunately, because I go back and forth between stations and files regularly, this sort of kills the usability for me.  Is there a way to tell it to ignore streams (not load ffmpeg)?

Man I love it when a plan comes together though.  The frequency legend is buff, BTW! 8)



Oh, crap.... I totally forgot that I supplied the 64bit version. I should fix that lol.

Forward and backslashes are interpreted the same way in this case.

Yep - saturation 0 causes it to be black and white. To be honest, the only reason I set it to that as the default is because I'm a lazy dev who prefers black and white, myself. The rest of the default settings are taken directly off of the Ffmpeg documentation site as their preferred defaults.

It's interesting that radio streams cause it to hang for you. To be honest, I never implemented any sort of check in there because streams don't cause my ffmpeg session to hang (or even execute in the first place). Now that I know it does, I'll take a look into it.

I have another flight tonight so I'll see what I can do.

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
It's interesting that radio streams cause it to hang for you. To be honest, I never implemented any sort of check in there because streams don't cause my ffmpeg session to hang (or even execute in the first place). Now that I know it does, I'll take a look into it.

Here once you switch to a stream, ffmpeg executes and hangs in memory;  while no image is shown in the window, a PNG with the initial track name is indeed generated inside Spectrogram_Images.  Maybe there is some way to have it recognize a url and not execute in that case.  Hey man forget it for today and enjoy that flight :)

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
It's interesting that radio streams cause it to hang for you. To be honest, I never implemented any sort of check in there because streams don't cause my ffmpeg session to hang (or even execute in the first place). Now that I know it does, I'll take a look into it.

Here once you switch to a stream, ffmpeg executes and hangs in memory;  while no image is shown in the window, a PNG with the initial track name is indeed generated inside Spectrogram_Images.  Maybe there is some way to have it recognize a url and not execute in that case.  Hey man forget it for today and enjoy that flight :)


New update to the link on page 1.

Update 5.4: Streams no longer cause Ffmpeg to hang. Ability to prevent the header (title bar) from being shown by manually creating a text file called "noheader.txt" in the Dependencies folder (USE AT YOUR OWN RISK).

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
Version 5.4:  streams no longer cause ffmpeg to hang.  Current behavior:

1.  If you start with playing a stream, no image is displayed or saved, continuing that way when switching streams (expected behavior).

2.  If you then play a song, image is displayed/saved (expected) with that song title.

3.  Once you switch back to a stream, no image is displayed, but an image identical to the song previously played is generated "behind the scenes" and saved with the stream's current title.  Continuing to a different stream produces no additional saved images, until you play a song, and switch back to a stream, in which case the behavior repeats.

To sum up, once the spectrogram is "activated" by playing a song, when you switch to streams a non-displayed image will be generated once for the first stream that is a copy of the previously-played song's image, and named/saved with the stream title.

Of course, all images get deleted on MB restart when that option is selected.  Question: is it possible to delete them instead on MusicBee's EXIT?  Also, can the "images have been deleted" message be suppressed?

So, the hanging ffmpeg problem is solved (thanks!).  The anomaly described above can be lived with IMO, but does generate unneeded additional images.  Thanks again for your work.

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
Version 5.4:  streams no longer cause ffmpeg to hang.  Current behavior:

1.  If you start with playing a stream, no image is displayed or saved, continuing that way when switching streams (expected behavior).

2.  If you then play a song, image is displayed/saved (expected) with that song title.

3.  Once you switch back to a stream, no image is displayed, but an image identical to the song previously played is generated "behind the scenes" and saved with the stream's current title.  Continuing to a different stream produces no additional saved images, until you play a song, and switch back to a stream, in which case the behavior repeats.

To sum up, once the spectrogram is "activated" by playing a song, when you switch to streams a non-displayed image will be generated once for the first stream that is a copy of the previously-played song's image, and named/saved with the stream title.

Of course, all images get deleted on MB restart when that option is selected.  Question: is it possible to delete them instead on MusicBee's EXIT?  Also, can the "images have been deleted" message be suppressed?

So, the hanging ffmpeg problem is solved (thanks!).  The anomaly described above can be lived with IMO, but does generate unneeded additional images.  Thanks again for your work.

Great catch. Thanks for all the troubleshooting.

I'll find a fix for this ASAP.

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
Actually, this isn't happening on my system. It might take a little while to trace it back to the source...

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
By "not happening", I assume you're seeing no PNG is being generated  by a stream just after switching from playing a file?  Just so I can supply some visual evidence that this indeed is happening here, below are two images:

Image #1, generated/displayed/saved by playing a song file just after starting MusicBee:




Image#2, generated and saved "incognito" but not displayed after first switching to a radio stream, identical to the song played beforehand:




The duplicate was however NAMED as being from the radio stream (vk.com--), as shown in the image folder contents:



If you're not seeing this, I can only guess it might be due to differences in how your version of ffmpeg is working as opposed to mine.  I am using the Zeranoe static build version 4.1.1, 32-bit.
Last Edit: February 27, 2019, 09:59:36 PM by sveakul

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
There are so many things that would have to happen for this to happen. Super weird.

Can you also ensure that there isn't another, older version of the add-in .dll located in App Data or something?

Could you run this debugging version and let me know what the pop-up says when it generates the 'incognito' one? I'm assuming that it creates a new Ffmpeg process, and this will enable you to see which commands it's passing to it.

https://www.mediafire.com/file/cgi7tg4ujboz8bt/mb_Spectrogram-Display.dll/file



I also realized that if you have the legend enabled, clicking on the track doesn't seek to the correct location due to the extended borders. I'm going to try to fix that.

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
Done;  here's the message generated after switching to a radio stream immediately after playing a song.  It first cites the previous song file's title, then shows an image being saved with the name of the radio stream instead:



No, there are no copies of the older plugin files around, I start every test of your new releases with a fresh MusicBee Portable backed up before I ever installed it.

SOMETHING funny is going on  :-\

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
Done;  here's the message generated after switching to a radio stream immediately after playing a song.  It first cites the previous song file's title, then shows an image being saved with the name of the radio stream instead:



No, there are no copies of the older plugin files around, I start every test of your new releases with a fresh MusicBee Portable backed up before I ever installed it.

SOMETHING funny is going on  :-\

The only thing I can think of is that for some reason it momentarily interprets the track duration to be greater than 0ms, so it triggers the generation of a new image. Since I added "mbApiInterface.NowPlaying_GetDuration() > 0" to prevent streams from prompting images to be generated (and it did prevent Ffmpeg from hanging), I believe that it might interpret buffered data from the stream as having a duration shortly after it begins playing.

Not only that, but ALSO, "mbApiInterface.NowPlaying_GetFileUrl()" would have to have a bug where it reports the last-played track, rather than the current stream name.


I don't have the time to fix the track-seeking issue tonight, but here's a version which will debug both of the API functions I referenced above. It will be a bit spammy with the prompts. In the future I might implement debugging which will go directly to a .txt file, but since this should be the last major issue for now, I'm doing it the crappy way.

LINK REMOVED

Thanks, again.
Last Edit: February 28, 2019, 07:40:05 PM by zkhcohen

sveakul

  • Sr. Member
  • ****
  • Posts: 2438
When I try to get the new debug file, MediaFire returns with "Download not available yet because the upload for this file is still in progress. Approximate completion time below (no time appears-svk)
Download ready soon…"

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
When I try to get the new debug file, MediaFire returns with "Download not available yet because the upload for this file is still in progress. Approximate completion time below (no time appears-svk)
Download ready soon…"

Mediafire didn't like it. Here you go:


EDIT: Wrong one, hold on.

EDIT 2: Ah crap. I overwrote it. Major changes in the next version anyway. I'll just send that one over when it's done.
Last Edit: February 28, 2019, 07:42:35 PM by zkhcohen