Activity for NLS
-
NLS posted a comment on ticket #1843
OK I have an update. It works! But there is still an issue. It takes maybe 30 seconds to actually reach the point where it starts to load. For this duration, the emulator is frozen. Seeing task manager, It calls unzip, first with parameter "-l", where it probably tries to see what is in the zip. Then calls unzip with "-p" parameter. To extract the t64 from the zip. BUT Then it calls unzip AGAIN with -l and then AGAIN with -p! The command line between "attempts" are the same. Only then it manages...
-
I cannot make further tests until tomorrow (or in two days), way to busy at work. Will revert.
-
Used this unzip: https://sourceforge.net/projects/gnuwin32/ ...dropped in both SDL and GTK executables home path. They both freeze when dropping the infamous zip file.
-
1) Well weirdly enough mine worked (the SDL version) WITHOUT unzip.exe in the path. :D I cannot verify any more though since I deleted the old install. 2) Without unzip.exe, if user tries to auto-attach a zip, it should just ask to provide unzip or pop an error. This is the "proper" intuitive behavior. Not fail unexpectedly by rendering the zip into a trash PRG within a (broken - see below) D64. 3) In my case in DirMaster, the D64 is trashed. Shows some control chars (not a proper dir) and as I said...
-
Just tested 43417. No go. Exactly same behaviour both SDL and GTK3. Does not detect Demons of Topaz T64 within zip file and instead tries to load a dummy D64 that it creates in appdata. Note that the dummy d64 doesn't have a proper directory list (DirMaster reports no proper directory and LOAD"$",8 loads forever), but DOES load something with "",8,1 (which reverts to READY.) Note, I cleaned my existing install and extracted the fresh one. So: - Does not detect that it is a T64. - Does not report...
-
Irrelevant of what happens, the program's handling of the situation is bad. In other words, if it can't uncompress something, it should NOT just consider it a D64 (it even drops some D64 in appdata - I didn't see what it supposedly contains) and "run" it. It should just report that it cannot do it. Also, if some extra executable or library is needed, it either needs to be in the package or in the requirements somewhere (is it?).
-
Also note that in the only one working properly (my SDL2 version on my mapped drive), I can visibly see a DOS window popping in and out a few times. It is ugly but seems it tries to run the zip extract command (and succeeds). In ALL other cases I don't see the DOS window popping up. If this means anything. In my mapped drive version I have WAY more files (esp. dll files) from older versions in the SDL2 root folder. Possibly one of these SOLVES the issue? (and if missing, like any fresh install, then...
-
In my regular setup: 3.7.1 r43409 GTK3 3.23.37, GLib 2.74.6, Cairo 1.17.8, Pango 1.50.11 SDL2 version doesn't report version in "about", but SDL2.dll is 2.26.3.0. In my local version (that I just extracted from download - same download as my regular setup though), everything is the same version EXCEPT GTK3 (wtf? how?) 3.24.37. Seems there is no correlation between SDL/GTK versions and the bug. 32 bit versions local react the same (buggy) as x64 local versions.
-
...and I have some VERY interesting results... 1) The zipped T64 itself, no matter if its local or on mapped drive. Same behavior. 2) The SDL and the GTK on two separate local folders... VERY insteresting. It is EVEN WORSE. :D I now have the confusion of zipped T64 as D64 in BOTH versions.
-
No zip, unzip in global paths. I will try from fresh, but still the bug remains even with those variables, as except if there is a conflict when dropping gtk over sdl where an executable (not the emulator itself) or library is same name BUT different content. I doubt this is the case. Network on mapped drive, shouldn't be an issue (and worked like that for years). Will get back with two fresh local folders.
-
But auto-attach zipped D64 works in GTK... if (un)zip didn't work, then any auto-attach would not work. Note that I use the same folder for both versions (as I noticed the overlaps are common files anyway). So my SDL vice is directly in VICE folder, while GTK binaries are in VICE/bin folder. Also I always (when I drop a new build) extract SDL first with "keep newer" and then GTK also with "keep newer" (which probably skips most files). This was never an issue - probably still is not (probably unrelated...
-
But auto-attach zipped D64 works in GTK... if (un)zip didn't work, then any auto-attach would not work. Note that I use the same folder for both versions (as I noticed the overlaps are common files anyway). So my SDL vice is directly in VICE folder, while GTK binaries are in VICE/bin folder. Also I always (when I drop a new build) extract SDL first with "keep newer" and then GTK also with "keep newer" (which probably skips most files). This was never an issue - probably still is not (probably unrelated...
-
But auto-attach zipped D64 works in GTK... if (un)zip didn't work, then any auto-attach would not work. Note that I use the same folder for both versions (as I noticed the overlaps are common files anyway). So my SDL vice is directly in VICE folder, while GTK binaries are in VICE/bin folder. Also I always (when I drop a new build) extract SDL first with "keep newer" and then GTK also with "keep newer" (which probably skips most files). This was never an issue - probably still is not (probably unrelated...
-
Also, I attach the log.
-
I just deleted my ini. I opened x64sc, it was immediately noticable that settings were reset. I dropped the zip I attach here, that contains a T64, on emulator window. It just started the auto-start from D64 sequence, instead of the tape one. In appdata, an "autostart-C64SC.d64" was created.
-
Auto-attach handles everything as D64?
-
You are right, I stand corrected.
-
erm... right :D
-
Be more flexible with different CRT sizes?
-
Thanks a "filename to title" would be lovely I guess.
-
In other words "hint hint: use TMDB instead" right? :D
-
Implement this for Refresh also maybe? Let me give an example in Greek (you don't need to understand Greek of course, just note that "Το" is an article in Greek - hope you read unicode properly): MC scrapes a movie and calls it "Το Ταξίδι του Χίκο (2020)". Me doing some manual work after that (because MC cannot cover me in this yet), I rename this like that (from file manager not MC): "Ταξίδι του Χίκο, Το (2020) [GR] (so I moved article to the end of the title and added a [GR] to help even family...
-
Thanks for all the answers. 5/6 - Well doesn't work all the time. But I suspect it is not an issue with MC, but maybe with IMDB API (I prefer IMDB). Maybe. 9 - I will get back to you on this because indeed it was very vague. Disregard for now.
-
I am using this for years, but I keep ignoring some issues I have and would love is someone could noob-spell me how to do the following... First of all I have a list of movies, already scrapped, so all my questions are meant on RE-doing some thing better. Right now I let MC work and then sometimes I do some additional work on the filenames etc. and press Refresh to re-read everything. 1) For movies (actually mostly animation) that are dubbed in my language, I like to add a tag [GR] in the end of...
-
I guess the subject is pretty much clear. Moving The, An, A is fine for English articles. Would love if MC understands and moves other language articles - and since I don't expect the program to actually know all articles maybe the three ticks need to be changed to a list (or even a list with an enable/disable flag for each entry), so that people can add (or remove, or disable) articles of other languages to move to the end.
-
Defining a second gamepad controls with no second gamepad, crashes dosbox.
-
-
Unbelievably enough I went in, exactly to ask this. I hope it is implemented eventually.
-
Unbelievably enough I went in, exactly to ask this. I hope it is implemented eventually.
-
This is possibly related to my last topic just posted. When during a long archive extraction, a second 7z instance (with different archive) cannot drag-n-drop. When trying to, it immediately results in "unspecified error" by 7z. Anyway around it, like transparently instructing 7z to queue the second extraction?
-
When I do a long extraction by drag-n-drop (either because the archive is big, or extraction is taking place over a slow VPN), seems I cannot drag-n-drop in Windows (Win10 x64, fully updated) at all. I mean even with irrelevant tasks like dragging normal files from a normal folder to another folder. Is this a known issue? Some limitation of Windows? (possibly because another drag-n-drop operation is pending?) Verified this on different computers. Any way around this and still using 7z drag-n-drop...
-
Actually is the program still under development? Nothing new for 1.5+ years...
-
Right now (at least in Windows), there is a huge difference between commanding 7zip to extract "extract here" (or in folder or whatever) using the context menu of Windows and opening the arcive and dragging-dropping the contents. In the first case it directly extracts to destination. In the second case it extracts to a temporary location and moves the contents to destination (so it takes longer and possibly doubles I/O). This big difference has the side-effects that in the first case 7zip handles...
-
This bug is still present in 37020 (and in between). As I said the problem is present with controller setting as "numpad". Is it possible it is related to repeat buffering?
-
Thanks for the calculations. (btw the block size of the parity disk was chosen for performance reasons, as I expected r/w with that block size) So since I cannot just kill so many GB of space in my data disks for my parity to fit, I will start looking at switching the parity to 4TB (and revert snapraid blocksize to something bigger). Or look for alternative solutions (i.e. non-snapraid - although with Windows host my options are limited). Extra (split) parity disk is not an option, no more space...
-
I wake this thread again, as I have the same problem. I have 9x3TB data disks and 3TB parity disk (minus about 2.5GB fir the copy of snapraid.content I have inb parity disk). Now my most filled disk has 121GB free. That disk holds 2.1mil files and 254k folders. My blocksize for snapraid is 128. My parity disk is (IIRC) formated with the biggest possible NTFS block size (since it just holds few huge files and nothing else). Still seems the above are not enough to make a new parity. I also tried with...
-
Makes sense. Actually I would probably delete both "content" files from P:. The point of having two locations is for SnapRAID to find at least one, to read it, right? Also I would delete the .tmp file from D:\snapraid as it is the "attempt" to male the new content file. So I'll probably just leave D:\snapraid\snapraid.content and let it sync. I would now have space in P: to create new content file (in D: it has enough space anyway). Thanks.
-
Depends on what you mean "software pro". I am in IT Professional, for more than 20 years. I started from development, but left this role behind (sometimes regret it). In any case I am pretty comfortable understanding "software stuff". I haven't touched anything, pending SnapRAID expert instructions.
-
OK so I have a configuration where snapraid.content is stored both in a disk external to the array (drive D:) and on parity disk (drive P:). In the latest sync I attempted the last few lines where: Using 4515 MiB of memory for the FileSystem. Initializing... Resizing... Saving state to D:/snapraid/snapraid.content... Saving state to P:/snapraid.content... Error writing the content file 'P:/snapraid.content.tmp'. No space left on device [28/112]. D:\SnapRAID> Result: P: has zero bytes free, P: has...
-
Build I use is GTK3 36175. Tested on two separate computers (both Win 10 x64). I verified it only does it with controller set as "Numpad". If I set to a keyset (I tested with cursor keys and with WASD), they don't stick. Also found an extra bug! If I define a keyset for controller, the numpad keys 7 8 5 1 2 3 / + .(comma or full stop, depending on locale) all produce "NUM_LOCK"! (9 4 6 are detected ok as NUM_9 etc.) BUT setting to "Numpad" the buttons are detected properly!
-
Controller direction sticks if button pressed for a while
-
Smart-attach disk image, doesn't work when image contains localized characters
-
Takes long time for me too. I have millions of small files (emulation data). Hope it gets implemented because I see this discussion is going on for years...
-
Thanks for the explanation. Indeed those disks have plenty of small files. I did move around a (big) folder to another disk to circumvent the problem. Not an easy decision as the thing is that (a) I don't want to break the logical layout of my folder organization, (b) I can't go around wasting 10%+ of each of at least half of my data disks (those that contain tiny computer emulation data). It is a huge amount of wasted space. I will build the parity now as is and probably for next sync I will experiment...
-
I have successfuly used SnapRAID for months and synced a few times too. I have 2-3 months to sync though. I tried to sync and got a huge list of files reporting "outofparity". In those 2-3 months I changed several GB of data and MOVED also several GB of data. All on the same disk (if I could see the quick scroll - I guess I could redirect the output of needed). It reports that I should "move the files to another data disk". Thing is, there is plenty of space on that disk. The data disks are 9, they...
-
I have successfuly used SnapRAID for months and synced a few times too. I have 2-3 months to sync though. I tried to sync and got a huge list of files reporting "outofparity". In those 2-3 months I changed several GB of data and MOVED also several GB of data. All on the same disk (if I could see the quick scroll - I guess I could redirect the output of needed). It reports that I should "move the files to another data disk". Thing is, there is plenty of space on that disk. The data disks are 9, they...
-
Add "true drive emulation" switch in bottom bar drive menu.
-
Tested in experimental build, for x64 and x128, seems to work well. Thanks.
-
Tested in experimental build, for x64 and x128, seems to work well. Thanks.
-
Hope you make one soon to test all the news things.
-
Thanks. Will wait for next experimental binary as I cannot compile were I am.
-
Are status messages common? I mean I use WinVICE for years but can't even remember what it reports down there. :D Jocking. In any case I don't think status space needs to be sacrificed. The status bar seems to already take two lines. At least in the most common (personal assumption) "double size" setting. Top line on the right, has (new) CRT controls, Tape, Drive. Bottom line on the right has (new) mixer settings and joysticks and then dead space under drive. In this space looks it can fit, maybe...
-
Right. Thanks.
-
Sorry indeed Windows, latest build. - Program icon. The program's... icon. On desktop (or filesystem). - File list. I mean Windows explorer. Same thing as above, bad phrasing.
-
Move CPU speed and FPS to task bar and make clickable for warp.
-
Click "joystick" task area to swap joystick ports.
-
Icons missing
-
The issue still remains in WinVICE 3.2 (yes I got the "we will not fix WinVICE before Gtk3 UI port"). I tried to autostart several (zipped) tap files. It stays in PRESS PLAY and cannot start it. No loading or saving of snapshots. My ini is still in WinVICE folder not appdata (and this is how I want it to be too), and indeed had "DATASETTE=0" in it. I switched it to 1 while WinVICE was running and it reverted to 0. Changing it without WinVICE running, does keep it 1. I suspect I did load a snapshot...
-
The issue still remains in WinVICE 3.2 (yes I got the "we will not fix WinVICE before Gtk3 UI port"). I tried to autostart several (zipped) tap files. It stays in PRESS PLAY and cannot start it. No loading or saving of snapshots.
-
Release schedule left behind?
-
I have a weird acess issue. The setup is simple: A veracrypt created volume file, created within a normal NTFS volume (Windows 10 Home). The encrypted volume itself is also NTFS (else I couldn't share it). There are also a couple of more Win 10 Home computers on the network. The volume is shared with full acess to them. Now the issue: If I create a folder using one of the other computers on the network (or use the folders already available and moved in the veracrypt encrypted volume), then the folder...
-
Actual audio to be used as tape input
-
Emulators seem to replace one another.
-
Changelog?
-
I understand. Unfortunately (would love it) I don't have the knowledge needed to...
-
Pointer to #201
-
2+ years later than this thread, there is still no new official release. I do follow...
-
+1
-
Thanks GPZ, never heard of that place before. GREAT! That said, it only demonstrates...
-
Releases
-
I have a huge installer that indeed has some corrupted data (running setup indeed...
1
