Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
16th September 2015, 20:52 | #4681 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Code:
2588 [Update] improved restart handling 2587 remove unnecessary runtime files at startup 2586 [Update] if a package needs to be enabled in the settings it will not be shown in the update window 2585 [DGIndexIM/NV] copy license.txt to the other indexer if possible |
17th September 2015, 06:24 | #4682 | Link |
Registered User
Join Date: Sep 2004
Location: Auckland, New Zealand
Posts: 466
|
I personally think that fixing up the profile saving\loading logic is more important. Nothing worse than MeGUI crashing or freezing mid encode and you have to kill the process only to find that it has nuked all your profiles.
Would it be easier to just disable the use of the updater if there is a worker in progress?
__________________
A Man Eating Duck Last edited by AMED; 17th September 2015 at 09:56. |
17th September 2015, 09:01 | #4683 | Link |
Registered User
Join Date: Feb 2011
Posts: 331
|
If one file in a folder cannot be encoded or there is an error with it, all other files in that folder are skipped when using one click encoder and adding the whole folder to be encoded.
I added 4 folders with video files to be encoded in xvid and in the 2nd folder there was an error with one file: Code:
error: The process cannot access the file 'G:\BackupWinD\Films\xxxxxx\Sezona 2\xxx - 07 - WHAT LIES AHEAD.mkv.lwi' because it is being used by another process. |
17th September 2015, 18:13 | #4684 | Link |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
The oneclick process is divided in two major parts: source preparation (extracting, indexing, ...) and encoding (audio/video, muxing). New jobs for new files are created at the end of the first part. So it looks like;
- source preparation file 1 - jobs for encoding file 1 are created - jobs for source preparation file 2 are created - encoding file 1 - source preparation file 2 - .... If the source preparation part fails it stops. This is the intended behavior as the indexing job does not know which files need to be processed lateron. Only possible change would be to create all "source preparation" steps of a folder at once but then all source files will be extracted first (which may be a problem for the storage space) and then all files are encoded (therefore the first file will be ready later). I may add an option to select these second work order but it will not be the default one. |
17th September 2015, 22:10 | #4686 | Link | |||
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Quote:
Quote:
Code:
2589 [Profile] "Load Defaults" resets the selected profile (before it was the scratchpad one) improved profile saving profiles will be saved to disk also when a profile is changed |
|||
18th September 2015, 19:06 | #4688 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Feature request:
Could we please have the old behaviour when modifying/saving presets returned (pre 2589)? I have an encoder preset I want to use, but I just want to change the CRF value (for example). Previously I could do so and the existing preset's settings would be copied to scratchpad. Now I either need to save a whole new preset, or over-write the existing preset, just to change one setting for a particular encode. The current behaviour seems like a step backwards to me, and I'm not sure what the point of having the scratchpad option is any longer. It's not even used when the default settings are loaded. I'll confess Zathor, the new behaviour doesn't make as much sense to me. I've rolled back to version 2584 for the moment. What was wrong with the way the preset system worked until now? Thanks. Last edited by hello_hello; 19th September 2015 at 13:09. |
19th September 2015, 16:17 | #4691 | Link |
Registered User
Join Date: Jan 2008
Posts: 571
|
Couldn't MeGUI start using system temp folder by default? I am trying to process ~100GB avi file with file indexer and it simply "kills" the regular HDD it is saved on after about 20 minutes. It just doesn't progress any further. Reading such humongous file and writing to the same disk at the same time doesn't really seem to work.
|
19th September 2015, 17:29 | #4692 | Link | |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
The system temp folder may be a bad choice so the user should select the temp drives. In OneClick mode no (big) file should be read & written on the same disk if selected properly. |
|
19th September 2015, 17:40 | #4693 | Link | |
Registered User
Join Date: Nov 2009
Posts: 2,405
|
Quote:
Code:
2590 [Profile] improved profile saving II fixed missing option to save to scratchpad (regression of 2589) |
|
19th September 2015, 19:04 | #4694 | Link | |
Registered User
Join Date: Jan 2008
Posts: 571
|
Quote:
You could add a global option to either enable system temp folder or specify a custom one. |
|
19th September 2015, 19:57 | #4695 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
In MeGUI's options there's one to specify the default output directory. When you open file with the File Indexer you can specify the location where the index file should be saved (audio being extracted should be extracted to the same location). The one exception might be indexing with L-Smash. At the moment the index file is created in the same directory as the source file then copied to the specified directory for the output files. I'd imagine that's some sort of limitation with the L-Smash indexer that prevents the index file from being written directly to the output directory, but Zathor can probably shed some light there. I think the L-Smash indexer always indexes any audio whether it's required or not (as opposed to ffms2, where MeGUI configures it not to index the audio if it's not selected in the File Indexer). For large files, especially those with multiple audio streams, that might slow the indexing process. I just tried a quick test with a 3GB MKV with 2 audio streams. Indexing time was 25 seconds for a 58mb index file (it appears to have indexed at least one of the audio streams even though no audio was selected in the file indexer). After I remuxed the same video as an MKV without audio, indexing took 16 seconds for a 10mb index file. For very large files containing audio, indexing the audio could make quite a difference. Maybe Zathor will know if it's possible to tell L-Smash not to index audio unless it's required. |
|
19th September 2015, 20:00 | #4696 | Link |
Registered User
Join Date: Jan 2008
Posts: 571
|
I have no idea what L-SMASH is, but it could be the case. I tried selecting different output folder (different physical disk) and it still took maybe 40 minutes (115GB file, sure, but the read speed is easily 80MB/s for that one).
|
19th September 2015, 20:08 | #4697 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Changing a preset gives the option to save the changes to scratchpad again, which is nice. It'll just take little while to get used to the "load defaults" function not loading the defaults in scratchpad as it did. I don't think that's a big deal either way. Maybe it'll be better as it is once I'm used to it..... Thanks again! |
|
19th September 2015, 20:20 | #4698 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
Depending on the file type, different indexers are used. There's a list when you open a file with the File Indexer and sometimes you can choose a different indexer (depending on the source file type). 40 minutes does sound like a long time, but depending on the file type and what's inside (multiple audio streams), it may not be for a 115GB file. |
|
19th September 2015, 20:29 | #4699 | Link |
Registered User
Join Date: Jan 2008
Posts: 571
|
I said it already, avi. All I know I clicked on file indexer, that's all I ever used. Sorry I don't understand the specifics of MeGUI very much, I learned one way to encode video years ago and just do that without really caring what it actually does.
|
20th September 2015, 07:28 | #4700 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
This is no satisfying amount of information. Never trust in a filename extension, there is always a chance that it has been renamed for the craziest reasons (e.g. people don't know how to assign a media player to an unassigned but correct extension so that it will start playing after a double-click in the Explorer).
To help us helping you, do an analysis of this source file using MediaInfo, and post the result in "Text" format in a CODE block (or in a pastebin service). If you are sure that it is an AVI because you made it, you may also know which codec was used; 115 GB is really huge, so it possibly contains completely uncompressed video. It would be a pity to have uncompressed RGB video saved, what a waste of space, and furthermore it is not the optimal color space as source for modern video codecs. This would also explain why the Indexer takes aged to build an index: It will write keyframe data for really every frame, because completely uncompressed video consists of keyframes everywhere. Such a video is hard to handle by L-SMASH Source. In this case only, AviSource is to be preferred. Last edited by LigH; 20th September 2015 at 07:33. |
|
|