If "keepOneEntry" is enabled the inputs of some recipes changed by UniDict changes every game-restart.
This effect seems to only apply to ores and dusts (never had it happen with anything else).
The main problem with this is that it makes it impossible to edit some Recipes through Mine-/Craft-/Mod-Tweaker as some CraftingManagers (like all ThermalExpansion Machines) only allow for the removal of recipes via the Input stacks (wich are not constant and thus throw errors every second restart).

[Tested with Version 2.8d on MC 1.7.10]

if your pack is this big, my computer isn't able to run it, since I have only 4 gigs of ram.
I will do some changes internally in the next update, it may improve the "consistency" of the results.
you are playing in 1.7.10, right?

//Sorry for the late replay, didn't have much time the last two days
I'm playing with over 250 mods, so I don't think a modlist would really help... (If I'm mistaken with that assumption, I'l gladly send it to you). Also the main problem seems to be the fact that UniDict isn't really recognizing the recipes at all (wich Inputs are used in the end is quite random as it jumps through all possible variants), so perhaps the loading order was messed up by something?
Also, though I don't know if it is related:
Whilst with simpler (10 mods) setups the Items selected by UniDict as highest prioritized keep their OreDict names the (bugged) inputs in my (larger) main setup loose them.

Yes.
Also, if I can help you with any tests or logfiles I'll gladly get them for you.

I was reading the code, and it not seems that needs to be changed, this issue is really weird, it should be consistent between the runtimes.
I don't think the log will help, unfortunately.

As I said before I think the problem probably lies semwhere in the timing of UniDicts actions compared to ThermalExpansion and Minetweaker accessing the OreDict.
Also is it intentional that the "Owning" // preferred items also loose their associated OreDictionary tags?
(Interestingly enough almost every "bugged" input is completely without any oreDict tags (even though it should have them)).
(Whilst trying (and failing) to replicate the issue with a smaller set of mods the items always kept their OreDict names...)

Also, another thing I just recognized: Sometimes it seems like its settling to one set of inputs, but whenever I try to interact with them through MineTweaker (or CraftTweaker as it is named nowadays) they change... (I ran it about 10 times... it's very unlikely to be just by chance)

UniDict sorts OreDictionary entries two times, one in the end of the Initialization Event and in the end of Post Initialization event, the first, is to guarantee some indirect integrations, the second, is to guarante if some mod registered items in the OreDictionary at post initialization event to be considered too (per example, AOBD, register thier things in Post Initi).
and, as far as I know, Minetweaker and such loads thier scrips in world loading.
then, UniDict can't unify things based in Minetweaker scripts.
I hope all this explanation makes sense, my english is not the best, sorry if I wrote something wrongly.
Thank you =P

Okay I kinda expected it to run prior to MT, wich results in it unifying things before any MT script edits the OreDictionary. Good to know it for sure now ^^ (Though that should be unrelated)

One more thing that probably is related: Whilst with smaller mod setups (where UniDict works perfectly) the 'owning' / preferred metals keep their OreDict Tags, in my 'buggy' setup they loose them.
I just re-read some of you code with that and your explanation in mind and I think I might have caught something: Could it be that you're (at least partly) removing OreDict Tags from the non-/lower prioritized metals during PreInit ?
If so that could in fact be the source of the problem as some mods don't fetch their inputs by the OreDictionary... (they just look for specific mods and then add recipes // copy recipes from vanilla handlers). As a result they would use Inputs that no longer carry their OreDict Tags und thus will not be changed. (Just assumptions built upon assumptions, so I could be completely wrong [I have the tendancy to theorize thing too much >.<] )

PS: Your english and explanation is perfectly understandable, so... 😄

Okay, the problem was right inbetween my screen and my chair >.<
and I can definitely rename this to a Feature-Request. #RantEnd
I thought UniDict didn't do something it was supposed to do (where I assumed wrong).

The thing I expected it to was replacing not only the outputs of recipes, but also the inputs.
[And I could have known it hadn't I in my infinite wisdom thought I wouldn't have to read the ModInteract Modules... //Okay too much ranting over my own stupidness already]

So TL:DR :
UniDict is Bug-Free, and this should be declared a feature request for UniDict to be able to not only replace the output of recipes but also the input (So for example: The InputStack for some Smelting recipe carrys the OreDictionary name "oreCopper" and is from another mod than the "owning" oreCopper it will be replaced by that one.)
[Recipe: Copper Ore {oreCopper} from ThermalExpansion --smelt--> Copper Ingot {ingotCopper} from ThermalExpansion]
whilst IC2 is declared as "ownerOfEveryMetal", copper is to be unified and inputReplacement is actiive would turn into
[Recipe: Copper Ore {oreCopper} from IC2 --smelt--> Copper Ingot {ingotCopper} from IC2]

UniDict should change the input of all the things? (Crafting Recipes, Furnace, Machines, and so on).
edit: the furnace does not support directly the Ore Dictionary.

Yes.
What I'm imagining would rely on the recipe using either an OreDictionary Entry (in wich case no action is needed anyways) or an Item/Block that has an OreDictionary Tag (like ores/ingots/dusts).
So, for example the Redstone Furnace (TE) takes TEs Copper ore as input for the Copper Ingot recipe.
With Input Replacement enabled that Ore would be replaced with the highest prioritized copper ore (in the same fashion as the output will be edited).
[If there are multiple recipes only one will be kept (should be simple to do as duplicate recipes would have In- and Output stacks)]
In the end it would be somewhat like forcing OreDictionary compatability.

I really don't know why UniDict is having these inconsistences.

I will give to you a better explanation of how it works.

the resources are gathered from the OreDictionary here wanion.unidict.resource.UniResourceHandler.java#L83

some of them are selected to be Unified according to the "metalsToUnify".
wanion.unidict.resource.UniResourceHandler.java#L127 then they are sorted wanion.unidict.common.Util.java#L26

the last step is upading these entries, wanion/unidict/resource/UniResourceHandler.java#L145, the ones that should be unified, are sorted again.

after all this, the Integrations are executed :)

sorry for the late reply.
to be completelly honest, I don't understood exactly what you are meaning, as i said, english is not my main language, lol.
I understood this way: if something wants a Copper ore from TE, per example, and the Copper Ore from IC2 is the main, change the input to IC2 Copper Ore?

Yes that is exactly what I meant ^^

Also, although I think UniDict is already doing that - the main ore/ingot/dust should keep its oreDictionary Tags/Names (In my setup some of them loose them if I remember correctly)

//English is a secondary language for me too xD Just have some years of practice :)

it is already doing it for some machines, the others that it is not doing it, is because they support OreDictionary(which means, I don't need to nothing with it) :)

now I am a little curious about where are you from.. lol
I am from the worst country of all, Brazil :(

Hm... interesting, at least TE seems to not properly adjust to the Oredict after Unidict is through with its' changes... probably the original cause of the inconsistant inputs it uses...
Would it be possible to check and (if needed) adjust just TEs recipes without too much work ?
(Although, for it to be effective it would have to run before cleaning up the Oredict)
(I think the problem is most likely being caused by TE grabbing its inputs from the Oredict at the wrong time for Unidict to really work with it)

To answer your question: I'm from Germany... don't really know how to feel about it...

I am still not sure why is having is these inconsistent recipes, but yeah, It is not difficult to do, but should be processing expensive.
no, UniDict create a "cache" before the OreDicts be cleaned up,

cool =D

TE input replacement is a little tricky, because of the way TE works.
but yeah, I may include this option in the next update, but no promises, thanks.

Thanks a lot for considering it :)

np :)

//Again sorry for the late reply
That's great news as it would be extremely helpful ^^
Regarding the processing extensitivity... I don't think anyone will really mind if the game takes a little longer to load (and I doubt anyone would even notice the difference). UniDIct is very lightweight in comparison to most other mods so that shouldn't really be a problem...

you mean TE Machines input replacement?
I created UniDict to be more optimized as possible, because I really need this kind of optimization in my future projects :)

The 'perfect' solution would be Input replacement for all processing machines that do not properly support the OreDictionary, but TE (as well as the smeltery although I don't really know how much control you have over that one) is the one causing the most problems in my opinion (For all others the static output allows MT/CT to work without larger issues).
(Toggleable via the config to allow deactivation if it isn't needed/wanted)

released UniDict-1.10.2-1.8 featuring Input Replacement.
1.7.10 release is coming soon.
edit: UniDict-1.7.10-2.9.1

Thanks for the report, this should never happen, since it uses the same algorithm that without it uses, so, it should affect even when keep one entry is false.
I will take a deep look in it, if possible, could you tell me the mods that you are using? to I be able to reproduce the issue.