Background JPG not loading - suggestions for troubleshooting? (was: file::exists false)

Hello everyone! I could use a second set of eyes on an bug reported by a user.

===========UPDATE============

I originally thought that the code that wasn’t loading the background first checked if the file exists. However, as I’ve been digging in, that’s probably not where the issue is happening.

==============================

A little while ago, Pgatt contacted me and said,

Just letting you know, I’ve seen a couple of bug reports in the last couple of days where Rack is crashing and Voxglitch is saying it can’t find a background, and then crashes. The first one I thought was just user error but I’ve now seen it three times in a short span.

[3.067 warn src/window/Window.cpp:844 loadImage] Cannot read file /Users/usersname/Documents/Rack2/plugins/voxglitch/res/themes/default/background2.jpg

In response, in order to patch this quickly, I added code to check to ensure that the background exists before attempting to load it. At the very least, this would avoid a crash. I knew that this wasn’t a good long-term fix. I knew that the missing background would still cause problems. I just wanted to buy myself some time to look into it.

Sure enough, a user contacted me soon after my update. Modues that were using my theming code weren’t loading their backgrounds:

There seemed to be some part of my theming system that wasn’t working for this Windows user.

I asked the user to confirm all of the paths and capitalization of the files and folders. He sent screen captures of the file locations, such as:

Everything looked OK to me. The log file that he sent me contained the following information about his system:

[0.003 info adapters/standalone.cpp:129 main] VCV Rack Free v2.1.2
[0.003 info adapters/standalone.cpp:130 main] Windows 10.0
[0.003 info adapters/standalone.cpp:136 main] Args: C:\Program Files\VCV\Rack2Free\Rack.exe 
[0.003 info adapters/standalone.cpp:139 main] System directory: C:\Program Files\VCV\Rack2Free
[0.003 info adapters/standalone.cpp:140 main] User directory: C:/Users/Aurélien/Passeport Elise/Rack2
[0.003 info adapters/standalone.cpp:144 main] System time: 2022-11-14 21:09:40 Paris, Madrid
[0.003 info src/settings.cpp:488 load] Loading settings C:/Users/Aurélien/Passeport Elise/Rack2/settings.json

Although the path to his User directory showed unusual characters in the log file, that didn’t pose an issue to other modules. For example:

[1.783 info src/window/Svg.cpp:28 loadFile] Loaded SVG C:/Users/Aurélien/Passeport Elise/Rack2/plugins/Prism/res/ComponentLibrary/prism_Switch3_2-08.svg

The code I use to load the reportedly missing background looks like:

  void addSVGLayer(std::string svg_path)
  {
    if(rack::system::exists(asset::plugin(pluginInstance, svg_path)))
    {
      std::shared_ptr<Svg> svg = APP->window->loadSvg(asset::plugin(pluginInstance, svg_path));
      VoxglitchPanel *voxglitch_panel = new VoxglitchPanel;
      voxglitch_panel->setBackground(svg);
      addChild(voxglitch_panel);
    }
  }

In the above code, rack::system::exists(asset::plugin(pluginInstance, svg_path)) is reporting false.

The immediate question that comes to mind is: What is svg_path set to?

That gets just a little bit complicated.

Step #1: A Voxglitch.json config file is loaded from asset::user. If it doesn’t exist, it’s copied into place from the res/ folder.

    if(! rack::system::exists(asset::user("Voxglitch.json")))
    {
      rack::system::copy(asset::plugin(pluginInstance, "res/voxglitch_config.json"), asset::user("Voxglitch.json"));
    }

Step #2: From there, it’s loaded and parsed to get the “theme” name, which is either “default” or “light”.

There are a few parts of this process which could quietly fail. I wouldn’t mind adding WARN messages if they did, but I haven’t gotten the OK to add WARN messages yet.

Regarless, my hunch is that, up to now, everything is functioning OK. Why? Because if you look at pgatt’s original error message:

Cannot read file /Users/usersname/Documents/Rack2/plugins/voxglitch/res/themes/default/background2.jpg

You can see that the “default” theme is being used. (It’s a long story, but I had the wrong default theme name set to “dark” when pgatt first reported the bug, so I knew that the correct “default” theme name was being loaded from the config file.)

Step #3: Each module has the following folders:

  • /res/{{module_name}}/themes/default
  • /res/{{module_name}}/themes/light

In each folder is a config.json which contains the path to the background file.

For example:

That theme configuration file is parsed and the path to the background is loaded.

The answer to the question, “What’s svg_path set to?” is:

/Users/{{ usersname }}/Documents/Rack2/plugins/voxglitch/res/themes/default/background2.jpg

I asked the user to confirm that those files existed, and he said that they do:

At this point, I’m rather stuck.

  • I don’t see any missing files on the user’s computer.
  • I don’t see any capitalization errors.
  • Although he’s using a different language for his Windows, it doesn’t seem to be a problem for any of his other modules.
  • Other Windows users are successful in using my modules
  • I don’t have any logging capabilities for learning more about his issue.

Any recommendations? Thanks!

On a Windows system, the first thing that jumps out at me is the missing drive letter. I would expect it to begin with “C:” or whatever his system drive is.

Unfortunately, I don’t think that’s the issue, because svg_path is being used in the call to:

if(rack::system::exists(asset::plugin(pluginInstance, svg_path)))

And asset::plugin() should provide the path to the plugin folder (including the drive letter I assume).

One gotcha with many join functions is, if the second argument begins with a slash or backslash, it will discard the first argument and just return the second. For example, join(“C:/Users/Fred”, “/Some/Path”) = “/Some/Path”. Do you have the original line from your log file that you can paste verbatim?

Is this a unicode issue? Haven’t read all the stuff, but if it’s a windows bug and it only happens with users that have non-ascii characters in their name…

1 Like

It certainly might be.

Sorry, I was wrong about the code that was loading the background image. It’s actually this:

APP->window->loadImage(asset::plugin(pluginInstance, this->image_file_path));

And here’s the line in my log file:

[2.048 info src/window/Window.cpp:73 loadFile] Loaded image C:/Users/clone/Documents/Rack2/plugins/voxglitch/res/themes/default/background2.jpg

(This succeeds on my Windows computer.)

Maybe I need some more time to look into this. The user is loading a .png file from the exact same folder that the background is in. There’s definitely something strange going on.

I was going to ask why that one file was a jpg instead of a png…

The background is really, really large and has no transparency, so it’s saved as a highly compressed jpg. The knob shadow has a transparency, thus the ping-ly-ness. :slight_smile:

OK. Can you link to your code? I’ll take a look and see if I can spot anything…

You bet! But give me a day or so. I learned something while typing this out and I might be on to something. At least – there’s new information for me to explore!

May be totally unrelated, it’s just year of customer bugs have ingrained in me "file path on windows, unicode, nightmare.

In my SFZ player I had to worry about it. Not apples to apples here, but I keep a folder of unicode stuff around for testing: image

I’m thinking this issue is some Unicode weirdness too. I would recommend trying to reproduce this issue on your own system by creating a directory with special characters in it, then use this as an alternate VCV Rack user data folder. You can then tell Rack to override the default directory on your system from the command line:

"C:\Program Files\VCV\Rack2Free\Rack.exe" -u "C:\MyTéstFölder"

Then you still have to debug the problem, but at least you don’t have to coordinate with somebody in France every time you want to try something!

2 Likes

ah, that’s the missing piece, yes. btw, for those that don’t know, linux and mac both use UTF-8 to represent stings in all languages, so those strings fit into std::string, and all the “normal” string operations work correctly.

Windows comes from an earlier era (like Java) where some optimists thought UTF-16 was the way to go. So since windows uses utf-16 for unicode strings you have to be much more careful and to a lot more work that make things like file names and paths work correctly.

1 Like

Perhaps this can be of use.

1 Like

yep, that’s a start (assuming you need to deal with it). Those functions are pretty small wrappers around native windows functions but that would probably save some time.

Rack has had fixes several times for users with “unicode” (or something) characters in their username. I’m thinking that maybe the same doesn’t go for all its dependencies? That should bite all other modules of course, except if you’re doing something that very few others do, which I don’t know in this case.

A couple of other things that strikes me from your examples:

  • C:/Users/Aurélien/ : That © character looks like something is misreading/interpreting the actual username. I cannot believe it’s part of the username.
  • /Passeport Elise/ : That’s a very unusual name for the “Documents” folder, I’ve never seen anything like it. Maybe someone French (or Spanish?) speaking could confirm that this is ordinary, otherwise my suspicion would be some kind of special software managing the documents directory, which doesn’t sound like a healthy recipe for Rack. Also strange that in the Windows Explorer screenshot, if it belongs to the same example, the folder is shown as “Documents.”

Thanks @LarsBjerregaard , I’ll look into this.

Today the user also reported:

I have a similar issue with SurgeXT plugins which are still on beta test. They don’t display properly both in the browser and on the rack.

This makes me think that my code may not be at fault. I’ll keep working on it.

1 Like

Previously, I was incorrect which line of code was probably causing the issue. Here’s where the background is loaded:

Which is called from:

I added a DEBUG to dump out the path string, which on my system contains:

[1.623 debug src/Common/components/VoxglitchModuleWidget.hpp:74 applyTheme] res/themes/default/background2.jpg

I also dumped out asset::plugin(pluginInstance, this->image_file_path), which looks good

[1.422 info src/window/Window.cpp:73 loadFile] Loaded image C:/Users/clone/Documents/Rack2/plugins/voxglitch/res/themes/default/background2.jpg

QUESTION

Am I doing anything wrong here? For example, I noticed that I’m calling loadImage ever frame. Is that OK?