Xk3y JPG Size & Number Limits Cause Drive/JPG Not Detected
Xk3y JPG Size & Number Limits Cause Drive/JPG Not Detected
Published byX_Splinter on 2013-01-22 Category: Custom USB Devices | Page Views: 3655
written by steven_gunnels @k3yforums.com
The simple rules for MENUISO=Y:
1.) All JPG files should have the exact same name as its corresponding ISO. Only the extensions differ.
2.) Every JPG file should be located in the same folder as its corresponding ISO.
3.) No single JPG file should ever exceed 192kb or 196,608 bytes in size.
4.) The total "size on disk" of all JPG files combined should not exceed approximately 9mb or 9,437,184 bytes (size on disk).
5.) While not absolute, you should separate games into sub-folders so that there are no more than 50-100 games per folder and 25-50 games per folder is better.
6.) Of course, make sure you have the latest firmware for the xk3y.
Alright. Lately, I have seen a lot of questions regarding problems detecting hard drives, especially after having added a few games and JPG's. There has been a lot of statements and speculation about this subject and most of them, it turns out, are wrong or inaccurate. Even I have made a few inaccurate speculations regarding memory usage and the menu ISO creation. Since there has been such difficulties and problems to arise from this, I decided to investigate it and find out for sure just what the limits and boundaries really are. Needless to say, the end result of 30+ hours of testing, tweaking, and retesting has lead to this post.
I believe this information should help alleviate significant problems that arise as the hard drives get larger and the number of ISO's increase. So at this point, I hope that a moderator or admin will sticky this post so that it might eliminate a lot of uncertainty and unnecessary posts asking for help. But if this doesn't occur, hopefully, it will at least be easy to search for.
Before I begin I will say that all tests were done with FW 1.28 and that all of the following information pertains to the use of the iso menu that is enabled in xkey.cfg by the line 'MENUISO=Y' and allows us to choose an ISO to mount through the picture viewer. This information also assumes that 'MENUDVD=N' and 'RESUMELAST=N'. At this point it is unknown whether or not setting either of these to 'Y' will alter the results. I do not believe that either of these settings could affect the first half regarding individual size limits of JPG files but it is possible that these settings may cause more memory to be used and further limit the latter half of this post regarding maximum number of JPG files. So now let me put some questions to rest by providing the accurate answers.
To begin with, it has been stated that the size limit of a JPG file is 200k. This is right and wrong, but mostly mathematically incorrect. (Again, this is assuming the use of 'MENUISO=Y. In the case of xk3y WiFi, these limits do not apply because the JPG files are read directly from the hard drive.) It would actually be more accurate to state that the JPG file cannot take up more than 200,000 bytes on disk, but this is not actually the size of the file itself.
Assuming the partition has 4k cluster size then the JPG size limit is 196,608 bytes or 192k.
Following are the tests that support this statement.
This should be fairly self explanatory but just to be clear I will explain it. The first number is the size reading you would get from Windows simply by highlighting the file and looking at size. The second set of numbers is obviously the dimensions of the JPG file that was being used. Following the dimensions is a statement that tells whether or not hard drive is detected and whether or not the picture would display when you go into picture viewer. Then, for the seven "borderline" files I provide the size in bytes accompanied by the actual size that is used on disk. This information is easily retrieved by right clicking on the JPG file and choosing properties. As you can see, the 'size' and 'size on disk' are usually different. This is because the partition uses 4k clusters, therefore the minimum size that any file can use "on disk" is 4096 bytes, or 4k.
716k file 353x500 - detects but fails to display
219k file 354x500 - detects but fails to display
198k file 703x1000 - detects but fails to display
194k file 355x500 - detects but fails to display - size 198,922 bytes - size on disk 200,704 bytes
192k file 425x600 - detects but fails to display - size 197,074 bytes - size on disk 200,704 bytes
192k file 702x1020 - detects but fails to display - size 196,797 bytes - size on disk 200,704 bytes
The limit on the number of JPG files is not quite so clear cut. The number of JPG files isn't as important as the total amount of memory that they occupy. Previously, I speculated that you probably have at least 20m but I was way off. After many tests I have gained the impression that it is likely that if you have so many JPG files that the total size falls within a certain range then it is likely that you might assume that the drive is not detected because the delay is so significant that you have to walk away and come back some minutes later before it finally detects.
The stable limit of the total size of all JPG files is approximately 8.5mb to 9mb.
Following are the tests that support this statement.
Again, this should be fairly self explanatory. The first number is the total number of JPG files. The second number which is after the @ symbol is the total size of all JPG files combined. Following the + symbol is the total ISO files. Then the statement indicates to what extent the drive or folder is detected. And finally, there is the size in bytes and size on disk.
102 JPG's @ 10.5mb + 320 ISO's - does not detect
102 JPG's @ 10.5mb + 102 ISO's - does not detect
102 JPG's @ 10.0mb + 102 ISO's - does not detect - size 1,545,849 bytes - size on disk 10,772,480 bytes
93 JPG's @ 9.30mb + 93 ISO's - does not detect - size 9,752,982 bytes - size on disk 9,961,472 bytes
92 JPG's @ 9.25mb + 92 ISO's - does not detect - size 9,707,892 bytes - size on disk 9,912,320 bytes
92 JPG's @ 9.18mb + 92 ISO's - does not detect - size 9,630,253 bytes - size on disk 9,834,496 bytes
92 JPG's @ 9.17mb + 92 ISO's - does not detect - size 9,625,747 bytes - size on disk 9,830,400 bytes
92 JPG's @ 9.17mb + 92 ISO's - inconsistently detected - size 9,617,050 bytes - size on disk 9,818,112 bytes
91 JPG's @ 9.16mb + 91 ISO's - inconsistently detected - size 9,614,004 bytes - size on disk 9,818,112 bytes
92 JPG's @ 9.16mb + 92 ISO's - inconsistently detected - size 9,613,787 bytes - size on disk 9,818,112 bytes
92 JPG's @ 9.16mb + 92 ISO's - inconsistently detected - size 9,611,843 bytes - size on disk 9,814,016 bytes
91 JPG's @ 9.14mb + 91 ISO's - inconsistently detected - size 9,585,508 bytes - size on disk 9,785,344 bytes
91 JPG's @ 9.13mb + 91 ISO's - inconsistently detected - size 9,580,831 bytes - size on disk 9,785,344 bytes
91 JPG's @ 9.12mb + 91 ISO's - detects SEE NOTE - size 9,572,268 bytes - size on disk 9,773,056 bytes
91 JPG's @ 9.11mb + 91 ISO's - detects SEE NOTE - size 9,552,908 bytes - size on disk 9,752,576 bytes
90 JPG's @ 9.05mb + 91 ISO's - detects SEE NOTE - size 9,494,629 bytes - size on disk 9,695,232 bytes
90 JPG's @ 9.00mb + 90 ISO's - detects SEE NOTE - size 9,445,819 bytes - size on disk 9,646,080 bytes
90 JPG's @ 8.99mb + 90 ISO's - detects SEE NOTE - size 9,435,694 bytes - size on disk 9,633,792 bytes
90 JPG's @ 8.99mb + 90 ISO's - detects SEE NOTE - size 9,433,225 bytes - size on disk 9,633,792 bytes
89 JPG's @ 8.93mb + 89 ISO's - detects SEE NOTE - size 9,374,290 bytes - size on disk 9,572,352 bytes
89 JPG's @ 8.90mb + 89 ISO's - detects SEE NOTE - size 9,338,160 bytes - size on disk 9,535,488 bytes
88 JPG's @ 8.83mb + 88 ISO's - detects properly - size 9,266,631 bytes - size on disk 9,461,760 bytes
85 JPG's @ 8.56mb + 85 ISO's - detects properly - size 8,978,192 bytes - size on disk 9,166,848 bytes
81 JPG's @ 8.18mb + 81 ISO's - detects properly - size 8,586,291 bytes - size on disk 8,773,632 bytes
64 JPG's @ 6.58mb + 64 ISO's - detects properly
130 JPG's @ 6.27mb + 130 ISO's - detects properly
42 JPG's @ 4.79mb + 42 ISO's - detects properly
20 JPG's @ 2.49mb + 20 ISO's - detects properly
NOTE: It seems that as we approach the memory limit of the xk3y, it begins to slow down. The closer to the limit that we come, the slower the xk3y responds. When opening the tray from the dashboard there is a noticable and significant lag time before the xk3y actually says "Tray Opening" and it takes a significant and noticable amount of time for it to actually mount the menu iso. Additionally, there seems to be occasional lockups if you open the tray and navigate too quickly. And finally, if you press a button on the remote to navigate the options while the ISO is being created the xk3y consistantly seems to lock up but if you are patient you will find that after a few minutes or so it will finally respond to the buttons that you pressed. Also, there is a certain range, as indicated above, that detection becomes inconsistant. Sometimes it will detect and other times it will not.
Considering 300 JPG files, as a rule of thumb, they should not total more than 9,437,184 bytes.
9,437,184 / 300 = 31,457.28 bytes per JPG
31,457.28 / 1024 = 30.72k per JPG
Because there are going to size vs. size on disk differences, make a rough estimate and expect that for 300 JPG files they will need to be no larger than 25k or 30k each. Or just get xk3y WiFi because with 400 ISO files the upper limit is 23k and that doesn't make for a very good picture.
Observations and after thoughts:
During the course of all of these tests I noticed a number of patterns and tendencies that tend to be indicative of certain operating procedures. Although I cannot be absolutely certain without more intimate knowledge of the xk3y, there are certain consistencies that lead me to a few assumptions and cause me to suspect a few things.
1.) When the hard drive is initially detected, the xk3y immediately begins scanning the 'games' directory.
2.) The xk3y scans the entire 'games' directory and all of its sub-directories every single time that the 360 is turned on and the xk3y boots.
3.) The more ISO's on the hard drive, the longer it takes for the 'HDD Detected'.
4.) If there is no 'games' directory then the 'HDD Detected' message shows up on the remote very quickly.
5.) If there is a 'games' directory then the 'HDD Detected' message shows up on the remote after the scan is complete.
6.) If 'MENUISO=Y' and there is a 'games' directory then the 'HDD Detected' message shows up on the remote after the scan is complete and the menu ISO has been created. (And it may lock up if JPG storage exceeds available memory.)
7.) When there are ISO files in the 'games' directory the hard drive is actually detected before the remote indicates it has been detected.
8.) I suspect the xk3y may use the Micro SD card as a cache, at least to a certain degree. The reason I suspect this is because when creating the menu ISO the xk3y exhibits significant slow downs indicative of caching when the total size of all the JPG files approach 9mb.
Now that these observations having been noted, I have a special request for BadSanta:
It seems to me that the amount of time spent on re-scanning the entire 'games' directory every time the system is turned on may be a little inefficient. If there are only a few ISO files in the 'games' directory, that scan is very quick, even unnoticeable. But the difference between a few ISO files, or even 50, and 350 is quite significant. I sometimes find myself wondering if the xk3y has locked or failed to detect the hard drive. I have been trying to get myself in the habit of turning the power on for the 360 and then going to make a pot of coffee before I come back to begin playing a game.
So, the request is to add yet another setting to the xkey.cfg file. Something like "GAMERESCAN=0/1/2 or Y/N". Assuming that you access (at least) some of the space on the SD card in the xk3y, you could write a games.cfg file there. Reading in a list of the games and locations of the ISO and JPG files from a text file should be a lot faster than rescanning the entire directory every time.
At first I thought "GAMERESCAN=Y/N" would be fine, but you wouldn't want to write the file every time you boot up if it is set to 'Y', which should be the default. The alternate idea was "GAMERESCAN=0/1/2" where '0' would read the contents of the games directory from a file, '1' would scan the games directory just as it currently does (and delete the games.cfg file if it exists on the SD card), and '2' would write the contents of the games director in list format into a games.cfg file. Again, this is assuming you have access and are able to write a small file to the SD card. Otherwise, if you cannot access and write to the SD, then "GAMERESCAN=Y/N" could still be implemented by allowing a games.cfg file to be created on the USB hard drive root director that has a list of the files in path file format "gamessubdirgame.iso".
Well, anyway, something like that. I think it would greatly improve the wait time with the larger drives that have an excessive amount of games on it.
Minecraft is Coming to Xbox Game Pass in April Microsoft has announced that Minecraft is making its way to Xbox Game Pass (@XboxGamePass) next month.Xbox Game Pass members will soon be able to create and explore their very own world where the only..