[APP][2.2+] MiXplorer v6.x Released (fully-featured file manager)

[IronTechmonkey]

I tried setting it to enabled and disabled but it makes no difference. I've tried everything I can think of. Uninstalling and reinstalling. Clearing the data, clearing cache. The popup will just not go away. It pops up every time I open the app. I can see my sdcard drive and read and write to it. Everything seems normal other than that stupid annoying popup every time. I have an external usb drive migrated to use storage for my Nvidia shield box. I have another Shield with basically the same setup and don't have this annoying popup. I just don't get it.

[edit] I installed X-Plore and it doesn't have any problems or any popups so I can't figure out for the life of me why Mixplorer does.

That is likely the popup for adding a document provider and it is not uncommon to be unable to add one at root of drive so we add it for each subfolder. That being said, such pop ups should only occur contextually as needed and not after being accommodated, I.E after installing MiX we may get one for /internalstorage/android/data because MiX needs to write there (rooted devices). Once the permission is granted, then prompt should not reoccur.

Apart from the pop-up can you write to the location for which you created document providers?

In any event this begs questions about the details of the device (android version, ROM variant, root status, other) and the drive (partitioning, formatting). IMO this is worth logging and sharing more details. Post 7 of FAQ describes how to use MiX's internal loging: https://forum.xda-developers.com/t/mixplorer-q-a-and-faq-user-manual.3308582/post-65157367

As to testing suggestions (which are easier said that done), after backing up all MiX settings (together and in their individual parts: app, bookmarks, skins) if you've got the time I would suggest the following.

- Confirm that there are no such issues when no OTG drives are attached, not just unmounted but physically disconnected).

- Remove any lingering bookmarks to OTG drives. If you encounter one that wont go away then that bookmark becomes a possible suspect and might be removed by a suggestion in this post: https://forum.xda-developers.com/t/mixplorer-q-a-and-faq-user-manual.3308582/post-85878051

- Test with a different external drive, something easy for Android to digest such as a small drive formatted FAT32, to see if that one can be granted access in a manner which does not cause the recurring prompt.

{EDIT] Corrected link to post containing suggestion for removing persistent OTG bookmark. Thanks @J.Michael

 

[woodside007]

I think I'll just go ahead and move on to using something else for that particular box. Funny that I have two exact Nvidia Shield boxes and I only have this problem with the one. To be honest it's not worth it for me to spend any more time on trying to get this popup to stop. I've spent all day. There are other apps that might not be so enriched with options as this one but will suffice for what I need at this time. Thanks for taking the time to respond. It is much appreciated.

 

[malim20]

@HootanParsa For JPEGXL, there is this:

GitHub - oupson/jxlviewer: A Jpeg XL viewer for android.

A Jpeg XL viewer for android. Contribute to oupson/jxlviewer development by creating an account on GitHub.

github.com

which provides a library. At the moment, I can't open jpegxl images from a Samba share as jxlviewer can't be chosen for some reason. It does work locally though.

And thank you for your work!

 

[LeshaRB]

How can I get rid of this warning?

 

[IronTechmonkey]

How can I get rid of this warning?

- Don't tap "Remove access".
- Tap 3 dot menu to see if there are other options.
- Based on Google search for "disable google third party access warning" check this: https://support.google.com/accounts/answer/3466521?hl=en,

In some cases this permission prompt may (or may not) be offered dynamically (eg as a MiX bookmark to google drive is being created) and there are posts relevant to that which can be found by search for 'third party access" (eg https://forum.xda-developers.com/t/...y-featured-file-manager.1523691/post-87696939), but you should be able to manage this from the google account settings.

 

[Collchuuk]

Hello again Mix developer(s). I have something else that I'd like to bring to your attention. This one is in regards to how newer versions of MIxplorer and certain addons treat video files stored on external storages. It's not that the files aren't opening and playing, it's that their thumbnails aren't generated at all. Like last time, I tested on two phones that are as similar as they can get. Again, I don't know whether to classify this as a bug, but it is new behavior.

In versions up until Mix 6.53.6-BETA 21032720, Codecs 2.4 2112103, thumbnail generation for certain video types acted like so, [View file S21+.png]

In the current versions, Mix 6.58.5 22020910, Codecs 2.4 2112103, thumbnail generation for certain video types act like so, [View file S22U.png]

Note: when stored on local storage, video thumbnails are generated as normal

I've included the log files of the actions and scenarios. (There was no new beta available, so I logged from the stable release) Included are also the video files used in the screenshots (the zip).
Thumbnails make it a lot easier to distinguish videos without having to open them. I hope that this will be addressed.

Devices used:
Portable SSD (EXFAT formatted)
S22 Ultra (Snapdragon 8 gen 1) (Android 13 | One UI 5) (Non-Rooted)
S21 Plus (Snapdragon 888) (Android 13 | One UI 5) (Non-Rooted)

I'm also going to link a previous issue I found as this and that may be related.

 

[J.Michael]

Hello again Mix developer(s). I have something else that I'd like to bring to your attention. This one is in regards to how newer versions of MIxplorer and certain addons treat video files stored on external storages. It's not that the files aren't opening and playing, it's that their thumbnails aren't generated at all. Like last time, I tested on two phones that are as similar as they can get. Again, I don't know whether to classify this as a bug, but it is new behavior.

In versions up until Mix 6.53.6-BETA 21032720, Codecs 2.4 2112103, thumbnail generation for certain video types acted like so, [View file S21+.png]

In the current versions, Mix 6.58.5 22020910, Codecs 2.4 2112103, thumbnail generation for certain video types act like so, [View file S22U.png]

Note: when stored on local storage, video thumbnails are generated as normal

I've included the log files of the actions and scenarios. (There was no new beta available, so I logged from the stable release) Included are also the video files used in the screenshots (the zip).
Thumbnails make it a lot easier to distinguish videos without having to open them. I hope that this will be addressed.

Devices used:
Portable SSD (EXFAT formatted)
S22 Ultra (Snapdragon 8 gen 1) (Android 13 | One UI 5) (Non-Rooted)
S21 Plus (Snapdragon 888) (Android 13 | One UI 5) (Non-Rooted)

I'm also going to link a previous issue I found as this and that may be related.

All I see in your pictures is (from old to new) the white cover disappears and the two green blobs turn red -- I don't see anything I would call a thumbnail, barely an icon. Did you post the pictures you meant to post?

 

[Collchuuk]

All I see in your pictures is (from old to new) the white cover disappears and the two green blobs turn red -- I don't see anything I would call a thumbnail, barely an icon. Did you post the pictures you meant to post?

1. I forgot to mention there irrelevance of the “CBZ_Test“ file.
2. Have you ever viewed videos (or images) in gallery or grid view in mix explorer? Have you ever noticed that instead of the ” red blob ”, a little snapshot of the video is shown instead? Mix refers to these as “thumbnails“. The files shown in the screenshot are all videos of a green picture (Except for the CBZ file). When thumbnails are turned on, a preview of the video should be shown instead of a " red blob ", hence the green squares in the first picture.

 

[J.Michael]

1. I forgot to mention there irrelevance of the “CBZ_Test“ file.
2. Have you ever viewed videos (or images) in gallery or grid view in mix explorer? Have you ever noticed that instead of the ” red blob ”, a little snapshot of the video is shown instead? Mix refers to these as “thumbnails“. The files shown in the screenshot are all videos of a green picture (Except for the CBZ file). When thumbnails are turned on, a preview of the video should be shown instead of a " red blob ", hence the green squares in the first picture.

I thought you were saying that the older version of Mixplorer was showing thumbnails.

Are you saying that neither version of Mixplorer displays thumbnails when viewing the external storage?

 

[atrk]

Hello! Is it possible to add ConnectBot to the list of supported terminals?

 

[Collchuuk]

I thought you were saying that the older version of Mixplorer was showing thumbnails.

Are you saying that neither version of Mixplorer displays thumbnails when viewing the external storage?

Yes (The first sentence), newer versions of MIX don't seem to generate thumbnails for videos stored on external storages.

If you go back to my original post, The screenshot titled ”S21+” is an old MIX version. The screenshot titled ”S22U” it's the newest version.

 

[IronTechmonkey]

FYI, regarding thumbnails. Depending on the specifications of the device thumbnail issue may be a previously reported new glitch or a variation thereof. Thread search for "thumbnails" yields reports of users unable to resolve this by known settings changes or workarounds; rather only by using previous version of MiX.

Search results for query: thumbnails

forum.xda-developers.com

 

[J.Michael]

Yes (The first sentence), newer versions of MIX don't seem to generate thumbnails for videos stored on external storages.

If you go back to my original post, The screenshot titled ”S21+” is an old MIX version. The screenshot titled ”S22U” it's the newest version.

Explain to me again how the older version of Mixplorer "generates thumbnails", but the picture named S21+.jpg does not show anything I recognize as a thumbnail.

Am I being too demanding of a "thumbnail"? I was expecting a successful thumbnail to be a tiny picture, with almost recognizable details: maybe a dog, maybe two people dancing, some picture from the movie. On what I thought was a picture of successful thumbnail production, I see some difference in the icons, but none of them looks like a picture.

 

[Collchuuk]

Explain to me again how the older version of Mixplorer "generates thumbnails", but the picture named S21+.jpg does not show anything I recognize as a thumbnail.

Am I being too demanding of a "thumbnail"? I was expecting a successful thumbnail to be a tiny picture, with almost recognizable details: maybe a dog, maybe two people dancing, some picture from the movie. On what I thought was a picture of successful thumbnail production, I see some difference in the icons, but none of them looks like a picture.

Try to ”play” the attached video files (One is in the zip file), notice how one is nothing but green. Next, download them and put them on your desktop. Assuming you have a valid video player installed, one's going to show up green and the other is going to have to default video icon. (See screenshot for expected result)

 

[IronTechmonkey]

.... I was expecting a successful thumbnail to be a tiny picture, with almost recognizable details: maybe a dog, maybe two people dancing, some picture from the movie...

... or a MiX thumbnail of a photo of an actual thumbnail on which a sample thumbnail has been drawn.

 

[IronTechmonkey]

Try to ”play” the attached video files (One is in the zip file), notice how one is nothing but green. Next, download them and put them on your desktop. Assuming you have a valid video player installed, one's going to show up green and the other is going to have to default video icon. (See screenshot for expected result)

FYI, the mp4 video in the zip file is only 28 bytes and seems unplayable in Windows media player, media player classic (part of Klite) or VLC (unziped with windows or 7-zip). As to green, thanks for the explanation. What threw me off there is that the green is similar to the color which some video editors use to represent masked areas of a project. In any event this may be a bit different from the other thumbnail issues or it could be part of a group of symptoms with a common cause.

 

[Collchuuk]

FYI, the mp4 video in the zip file is only 28 bytes and seems unplayable in Windows media player, media player classic (part of Klite) or VLC (unziped with windows or 7-zip).

Yep that's intended, it's literally just text file renamed as MP4 file. This was done so that it will be ”unplayabe” so that the default icon for MP4 files would be displayed instead of a regular thumbnail.

Open it up with a text editor to see what I mean.

 

[zgfg]

Yep that's intended, it's literally just text file renamed as MP4 file. This was done so that it will be ”unplayabe” so that the default icon for MP4 files would be displayed instead of a regular thumbnail.

Open it up with a text editor to see what I mean.

For me, that's pretty stupid if something creates a thumbnail for the file that is actually not a media file - and certainly, I would not be happy with, and would never want that as a 'feature'

It actually means that it does not even check if the file is correct media file or not

Btw, trying to play with the other player displays an error, while Opening as Text detects that it was indeed a text file containing the text: "This used to be a text file"

And btw, when I click on your first attachment then it is the browser (Chrome in my case) that incorrectly 'plays' the green.mp4 as a 'green' video - it should do better, it had to recognize from the missing MP4 header that it was not really an MP4 file

 

[IronTechmonkey]

For me, that's pretty stupid if something creates a thumbnail for the file that is actually not a media file - and certainly, I would not be happy with, and would never want that as a 'feature'

Unless I'm misunderstanding you this is already a "feature" of most OS and file managers, as most of them still use file extension as primary identification, in addition to dynamic and context-sensitive scanning to find thumbnails and populate media library with information, etc.

After all, we would not want it to be up to the OS or file manager to decide that a file with a name extension matching a particular media type is not valid media of that type merely because the OS or file manager cannot generate a thumbnail for it. IMO there is to much variability in the universe of containers, codecs and file types to allow an OS or file manager to make that decision because if it did then we could loose older, alternate, obscure, or experimental media formats which fit into a particular container (eg MP4 or MPG)

It actually means that it does not even check if the file is correct media file or not

...or it checked and found nothing it could interpret as a thumbnail and so then used the generic icon matching the file name extension.

 

[zgfg]

...or it checked and found nothing it could interpret as a thumbnail and so then used the generic icon matching the file name extension.

It's absolutely easy to check if a file includes jpeg, mpeg, etc header - it does not require to decode the media content