Cannot load VLC installed via Flatpak #79
Comments
|
Images for proof: Video Link: Image Link: |
|
Log from Prism Launcher: |
|
VLC is Installed |
|
you installed VLC via flatpak or Pakman? consider use apt instead, because flatpak have a sandbox filesystem that doesn't let other things be readed. |
|
i transfered the issue to WATERMeDIA because the issue is for that lib |
SrRapero720
added
Bug: API
I installed it via flatpak |
Can confirm, this issue occurs with apt anyways. I'm on Debian 12 latest with VLC installed via apt and I still cannot view videos. |
Another thing, this isn't true! Flatpak just runs applications in a sandbox environment to protect users. Whilst the files still persist on your drive and can be accessed (for example, atlauncher via Flatpak is located at The issue (i assume from looking at the other directories) is because Watermedia isn't looking inside the vlc directory in x64_64-linux-gnu at https://github.com/SrRapero720/watermedia/blob/4cd8a933990a5dbbc4d2d80d5f2483e96c5811d4/lib-vlcj/src/main/java/uk/co/caprica/vlcj/discovery/provider/LinuxWellKnownDirectoryProvider.java#L31 Adding the directory: |
|
Actually, i'll just PR this myself to test that this is right. |
|
So, I was wrong. Upon further inspection, it turns out that, not only is Pulling your 2.0.x branch and changing the find function to be: private String find(String directoryName) {
try(DirectoryStream<Path> rootFolder = Files.newDirectoryStream(getSymLinkPathOrSelf(Paths.get(directoryName)).toPath())) {
if (rootFolder == null) {
File rootFile = new File(directoryName);
LOGGER.debug(IT, "Cannot search on '{}', exists: {} - isDirectory: {} - canRead: {} - canExecute: {} ", directoryName, rootFile.exists(), rootFile.isDirectory(), rootFile.canRead(), rootFile.canExecute());
return null;
}
LOGGER.info(IT, "Searching EPIC FILE on '{}'", directoryName);
Set<String> matches = new HashSet<>(patternsToMatch.length);
for (Path mainFile : rootFolder) {
System.out.println("File name: " + mainFile.getFileName().toString());
if (Files.isDirectory(mainFile)) continue;
// check files directly
for (Pattern pattern : patternsToMatch) {
System.out.println("Pattern to match: " + pattern.pattern());
Matcher matcher = pattern.matcher(mainFile.getFileName().toString());
if (matcher.matches()) {
System.out.println("Matches!");
// A match was found for this pattern (note that it may be possible to match multiple times, any
// one of those matches will do so a Set is used to ignore duplicates)
matches.add(pattern.pattern());
if (matches.size() == patternsToMatch.length) {
return directoryName;
}
}
}
}
System.out.println("Looped successfully!");
} catch (Exception ignored) {
System.out.println("EXCEPTION!!");
}
return null;
}Sees the For more context, It seems like the for loop is being cutoff by something (forge preventing this from taking too long?) so Watermedia is unable to find the VLC file. Taking the code into a standalone project: public static Pattern[] patternsToMatch;
public static void main(String[] args) {
patternsToMatch = new Pattern[1];
patternsToMatch[0] = Pattern.compile("libvlc\\.so(?:\\.\\d)*");
try(DirectoryStream<Path> rootFolder = Files.newDirectoryStream(getSymLinkPathOrSelf(Paths.get("/usr/lib/x86_64-linux-gnu")).toPath())) {
for (Path mainFile : rootFolder) {
System.out.println("File name: " + mainFile.getFileName().toString());
if (Files.isDirectory(mainFile)) continue;
for (Pattern pattern : patternsToMatch) {
System.out.println("Pattern to match: " + pattern.pattern());
Matcher matcher = pattern.matcher(mainFile.getFileName().toString());
if (matcher.matches()) {
System.out.println("Matches!");
}
}
}
} catch (Exception ignored) {
}
}
private static File getSymLinkPathOrSelf(Path path) {
if (!Files.isSymbolicLink(path)) return path.toFile();
try {
File symLink = Files.readSymbolicLink(path).toFile();
return symLink;
} catch (Exception ignored) {}
return path.toFile();
}I can see it finds the file correctly and shows "Matches!" I would heavily suggest you find out why in your own time for your next version. For now, I'm going to add a PR that will try see if VLC exists in specific files and use that, allowing this as a backup (that will most likely fail). |
|
God this has been a nightmare, anyways, I've figured it out without needing a PR! Turns out, if you use ATLauncher via flatpak it doesn't see VLC files (should of guessed that before all this testing huh). In other words, @Mark6O9, make sure your ATLauncher isn't installed via Flatpak otherwise you won't be able to see Videos! Going forward, @SrRapero720, you should add a notice to your README that states this mod does NOT work with any minecraft launcher/instance from Flatpak. Hope this helps! |
Thats because when the SET is done (all are matched) the for loop is interrumped by the return block inside of the Matches check
If forge or neoforge do that they probably will be totally avoided for modding, because that will lead in a tons of crashes. Forge bootstrapping is offthread, so isn't affecting any modloading process for other mods
No matters even if you install Minecraft out Flatpak, you cannot open VLC files if are managed by the flatpak FileSystem
I was forgetting about do that for a long time. i'll make sure i add it on readme (or wiki) |
SrRapero720
changed the title
|
For future references, VLC cannot be loaded if was installed via Flatpak, neither if launcher/minecraft was installed via Flatpak No, i cannot give support due to flatpak FileSystem limitations. PRs for workarrounds are welcome but i have no plans to support a sandboxed installation |
My friend and I were going to play around with this mod on their mod pack, but they told me that videos don't work. Me testing it in a single player world showed that videos don't work except images do work. We both think it could just be an issue for Linux and Windows is the only way to get this mod to work. However we also came to the theory that it just needs to be pointed to VLC on Linux.
The text was updated successfully, but these errors were encountered: