-->> Shark's website <<--

Shark's Help Forum

Search
  Create an account  
Bug Report - REl 3.3.0 Final

#1
Hello, Xanashi....
I hope all is well.  Can you clarify how you want users to log/report bugs.  Here, or in the issues tracker.  I'll follow your standard once I know what it is for sure ! ;-)  Thank you again for this latest release.  Your hard work and great app is very much appreciated.

So, this is brand new for me.  I was attempting to use the "Debug" functionality.  This is one that I've used in the past, and it's typically run without a hitch.  Now, when I attempt to drag a folder to this page, it gives me the following error (see attached).  I've tried various folders, various network and non-network drives, all the same results.  When I click close, the app remains open.  Any additional debug info I can provide let me know.

Update, I had just thought to try some individual files, and I get the same error.  I've also uninstalled the app, rebooted and installed again.  I still receive the same error in all tests.

Thanks !

Matt R.


   
Reply

#2
I can confirm that this happens to me too. I just tried it. The paths contain no illegal characters, only those used in English/Latin.
Reply

#3
This is definitely something that needs to be fixed soon.

Could you both tell me a bit about your systems. 

What version of Windows.
Are you using local Windows accounts.
Are you experiencing this issue with files located locally on your system, or 
is it files from network drives?
Can you give an example file path of one of your files (with all private information replaced with placeholders)?

Anything else that may be different in your system setup compared to a default
Windows installation?

The problem is currently that I can't reproduce this issue on any of my machines
or VMs.
Reply

#4
I do not regard this as an important bug, because it only affects the debug tool? It runs fine otherwise.

My system: Windows 10 Pro 64-bit, 10.0.19042.804. (Yeah, I have stopped updating it. But everything .Net-related should be up-to-date.)
Local account, local files. No cloud drive, no network.
I built this thing myself, and I don't see what could be different to a regular office PC. I also use other shell extensions, but I do not see how they could cause a negative impact on a common drag&drop action. My Windows thumbnail cache is stored on a secondary SSD via a symlink.

Example paths: *Any* path?

O:\Folder\2022-12-21T08-19-29.mp4

U:\2022-12-23T08-47-18.mkv

C:\Windows\Web\Screen\img101.png

It says there are illegal characters in the path, just like on the screenshot.

C:, U:, and O: are all physically different disks.

This bug also occurs in a Windows 10 virtual machine running 19041.207.
Reply

#5
(01-20-2023, 01:45 PM)Zelanium Wrote: I do not regard this as an important bug, because it only affects the debug tool? It runs fine otherwise.

My system: Windows 10 Pro 64-bit, 10.0.19042.804. (Yeah, I have stopped updating it. But everything .Net-related should be up-to-date.)
Local account, local files. No cloud drive, no network.
I built this thing myself, and I don't see what could be different to a regular office PC. I also use other shell extensions, but I do not see how they could cause a negative impact on a common drag&drop action. My Windows thumbnail cache is stored on a secondary SSD via a symlink.

Example paths: *Any* path?

O:\Folder\2022-12-21T08-19-29.mp4

U:\2022-12-23T08-47-18.mkv

C:\Windows\Web\Screen\img101.png

It says there are illegal characters in the path, just like on the screenshot.

C:, U:, and O: are all physically different disks.

This bug also occurs in a Windows 10 virtual machine running 19041.207.

Thank you so much for your help troubleshooting this.
I've finally figured out what was wrong. I'll post a test build as soon as I can, so we can make sure the problem is fixed on all systems.
Reply

#6
I’m glad if I was able to be of any use to you, given how much your application has helped me. If you wish to release a new build, I’d like to alert you to another issue which I regard as minor: It seems that Icaros isn’t using embedded webp covers.

To make this short, I sometimes download videos from YouTube with youtube-dl, and always tell it to embed the YouTube thumbnail in the video. If these are cover.jpg or cover.png files (embedded within the media files), Icaros uses them as a thumbnail. But recently, YouTube has apparently started using webp images as thumbnails. All videos downloaded from YouTube (at least mkv files) now carry an embedded cover.webp, and Icaros gives me a generic thumbnail, ignoring the embedded cover due to its webp extension, as it seems.

I tested this in my virtual machine to make sure the thumbnail cache doesn’t interfere, and checking "Use any embedded image as cover" also doesn’t fix it. Bottom line is, it seems Icaros isn’t using embedded cover.webp images like it uses cover.png and cover.jpg. (The webp covers are there, and I checked how they look like by extracting them.)

Due to family and work-related reasons, I won’t have access to my desktop PC for the next days, so I probably won’t be able to provide any more feedback in time, although I don’t see what else I could say. If the webp cover issue concerns you, you can easily make such files yourself by downloading yt-dlg, using a recent version of the youtube-dl backend (all free), and downloading any recent YouTube video of your choice with the option "Embed thumbnail in audio file" checked. An example command line syntax is
-f "bestvideo[height<=720][fps<=30]+bestaudio" --no-playlist --ffmpeg-location "I:\ FFMPEG"
which should download you a video at a reasonable file size with an embedded cover.webp. It is most likely an mkv file; mp4s downloaded from YouTube come without any cover. Again, older mkv downloads have a cover.png which Icaros uses as the thumbnail.

Evidently, it’s not a big problem and rather a cosmetic affair, but given webp files are becoming more and more common it is reasonable that they should be treated like jpg and png cover files, as long as Icaros does support the format internally.

Thank you again for your time and efforts. You are a true blessing to my Windows experience.
Reply

#7
Hi Mrantz and Zelanium,

Could you both try the following fix for the "illegal char... in path" error. (if and when you have the time of course).
IcarosConfig now uses .NET 4.6, but if you're on Windows 10+, no additional download should be required. 

Otherwise installing .NET 4.6 is required: 
https://download.microsoft.com/download/...OS-ENU.exe

Test build:
https://www.mediafire.com/file/igujworq9...x.zip/file

@Zelanium
Sounds like an easy fix. I'll be sure to take a look at it. 
I already have youtube-dl, so it should be easy to test. 
Thank you for making me aware of it.
Reply

#8
(01-21-2023, 11:19 AM)Xanashi Wrote: Hi Mrantz and Zelanium,

Could you both try the following fix for the "illegal char... in path" error. (if and when you have the time of course).
IcarosConfig now uses .NET 4.6, but if you're on Windows 10+, no additional download should be required. 

Otherwise installing .NET 4.6 is required: 
https://download.microsoft.com/download/...OS-ENU.exe

Test build:
https://www.mediafire.com/file/igujworq9...x.zip/file

@Zelanium
Sounds like an easy fix. I'll be sure to take a look at it. 
I already have youtube-dl, so it should be easy to test. 
Thank you for making me aware of it.

Xanashi -

Sorry I have not had a chance to check back in until now.  It looks like you've got the illegal char error resolved !!  I downloaded your zip file, and unzipped the contents into the Icaros program folder, and ran it.  The various test folders that gave me the error before ran this time without a problem. 
NOTE:  I'm on Windows 10.  No additional downloads were necessary.

2/15/2023 - Add'l Note:  So far so good - Debug is running perfectly (from what I'm seeing).  Done a bunch more "Debug" runs with numerous different network & local computer folders with hundreds of video/jpg files in them with ZERO issues ! Awesome work ! Thanks !

2/15/2023 - Add'l Note 2:  Just an FYI. Running the official last release of Icaros (not this test version with the debug fix), I was having a random event happening, pretty regularly, but not on any particular schedule that I could tell anyways, where the Icaros cache would suddenly be wiped out and start rebuilding from scratch.  I really wouldn't notice when it happened, but once in a while I would launch the app and by chance notice that the cache size was say now 800 MB, where it had been over 5 GB of data  the last time I noted it. I never did report this issue, because I really had no solid information that I could provide to indicate any particular timing or event that would have been causing it. I was pretty certain that there wasn't any type of system event that was being triggered that would delete the cache file, forcing Icaros to start the build from scratch again. I even searched through the entries in Windows Event Viewer, and there were ZERO entries regarding Icaros or any possible related events.  HOWEVER - This random event HAS NOT been noticed since I've installed and been running this special test version of Icaros.  I'm only providing this as information to you, there's nothing for you to do or spend time on.  I'll post something if I notice this happening again in the future, or maybe someone else who reads this has noted the same thing, and can provide some additional info that I can not....Thanks!

Thanks again for all your hard work on this great application.

-Matt
Reply

#9
Hi Matt,

Sorry that I never replied to your feedback.
Thank you so much for testing and confirming that the fix worked as intended. 
And also awesome that I potentially fixed another bug with all the latest improvements to the cache.
I'll take it!
Reply





Users browsing this thread:
1 Guest(s)