GitHub and My computer problems
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
Re: My computer problems
Regarding the antrun plugin, they broke it here: https://github.com/UniversalMediaServer ... 81d38450f6
..then they fixed it again here: https://github.com/UniversalMediaServer ... b507c9861a
..and then broke it again here: https://github.com/UniversalMediaServer ... b705fdec1a
I really have no idea why they have done this, it seems very strange to me to break Eclipse compatibility when there is absolutely no benefit in removing that configuration.
If you check out the last commit before it was broken, you should get rid of the error and be able to build. To do that, "cd" to the folder where you have cloned UMS ("UniversalMediaServer") and run:
Later versions will probably build just fine if you add what was removed in 6e57307ff1397cf2b5f8a64ad83f1cb705fdec1a back into pom.xml. This can easily get tiresome though, I don't know if they plan to keep it broken for all that use Eclipse.
After you have checked out a working commit, right-click "ums" in "overview" on the left side and select Maven -> Update project. That will make Eclipse re-read the Maven configuration and figure out that it's now ok, so your error should go away.
..then they fixed it again here: https://github.com/UniversalMediaServer ... b507c9861a
..and then broke it again here: https://github.com/UniversalMediaServer ... b705fdec1a
I really have no idea why they have done this, it seems very strange to me to break Eclipse compatibility when there is absolutely no benefit in removing that configuration.
If you check out the last commit before it was broken, you should get rid of the error and be able to build. To do that, "cd" to the folder where you have cloned UMS ("UniversalMediaServer") and run:
Code: Select all
git checkout 84c1f5908482a8978632328d0fe5ed7c3ddc1dc2
After you have checked out a working commit, right-click "ums" in "overview" on the left side and select Maven -> Update project. That will make Eclipse re-read the Maven configuration and figure out that it's now ok, so your error should go away.
Re: GitHub and My computer problems
@mik_s If something is unclear, don't hesitate to say so. The thing is that there are so many things to potentially explain, it all depends on previous experience and knowledge. I kind of have a history of writing pages upon pages with stuff people already know, and since that feels like such a waste I try to not go into more detail than necessary. It is not an expression of an expectation that you should know or understand a certain thing, I simply try to guess as best as I can what should be explained and what shouldn't.
In addition, it's difficult for me to put myself properly in your position, you probably feel that you're met with a storm of new terms, concepts and names which can be difficult to get a clear view of when they come in to big chunks. For the things I'm already familiar with, this obviously isn't the case for me, so my experience tells me that I'm not the best of estimating "the amount of overload" the other person might experience. I see others do the same to me when they have knowledge of things I don't, so I assume it's a human weakness
So, in short, instead of trying to twist your mind making sense of some of the things I've written, or that some of the new tools does, just ask. It's much easier to answer when I know what needs explaining
In addition, it's difficult for me to put myself properly in your position, you probably feel that you're met with a storm of new terms, concepts and names which can be difficult to get a clear view of when they come in to big chunks. For the things I'm already familiar with, this obviously isn't the case for me, so my experience tells me that I'm not the best of estimating "the amount of overload" the other person might experience. I see others do the same to me when they have knowledge of things I don't, so I assume it's a human weakness
So, in short, instead of trying to twist your mind making sense of some of the things I've written, or that some of the new tools does, just ask. It's much easier to answer when I know what needs explaining
Re: GitHub and My computer problems
Don't worry I'll probably be bugging you a lot on how to go about things 
Feel free to point me in the direction of some guides or videos if you don't want to write pages, I'll pick it up eventually.
The closest thing to an IDE I have used in the past was doing some programming on an Arduino. Git is completely new but I get the idea of it now.
I can usually follow code once I get used to the syntax, at least up to a point. Loops and conditional statements I can understand but usually at the heart there is some clever line that does something that I just can't get my head around, even harder if it is using RegEx.
I managed to do the checkout and that fixed the error, but would be better if I was using the latest version.
what would I need to add back to the pom.xml (I keep thinking the m is rn
)
Tried to "debug as java application" and seems to start building OK, but I get the message in the console "File not found: P:\test\heapdumpc"
I'm definitely feeling the effects of only having half the memory I used to have, but looks like I'm stuck with it as new one costs too much for me at the moment.
If I can figure which chip is bad on the stick maybe I could just get a new chip and replace it. My dad has has a hot air station to do it, but because of this lockdown it would be a while before I can get it.
Feel free to point me in the direction of some guides or videos if you don't want to write pages, I'll pick it up eventually.
The closest thing to an IDE I have used in the past was doing some programming on an Arduino. Git is completely new but I get the idea of it now.
I can usually follow code once I get used to the syntax, at least up to a point. Loops and conditional statements I can understand but usually at the heart there is some clever line that does something that I just can't get my head around, even harder if it is using RegEx.
I managed to do the checkout and that fixed the error, but would be better if I was using the latest version.
what would I need to add back to the pom.xml (I keep thinking the m is rn
)Tried to "debug as java application" and seems to start building OK, but I get the message in the console "File not found: P:\test\heapdumpc"
I'm definitely feeling the effects of only having half the memory I used to have, but looks like I'm stuck with it as new one costs too much for me at the moment.
If I can figure which chip is bad on the stick maybe I could just get a new chip and replace it. My dad has has a hot air station to do it, but because of this lockdown it would be a while before I can get it.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: GitHub and My computer problems
Don't worry if you're confused by the code, I'm confused by the code all the time, and I've written over 200 000 lines of it. Regardless of if you understand the syntax (regex or not 
), it's hard to understand a piece of code until you understand the logic. If the person who wrote it used descriptive names, was tidy and potentially commented where things weren't obvious, it might not be so difficult. Most of the time however, this isn't the case.
About the m2e error, what you need to do is to paste the text that was removed in the commit I linked to, in the same location in porn.xml where it was removed. That is tiresome though, as you must do that every time you check out a commit. A better solution would be if the UMS devs would fix it. This isn't a problem only for you, this is a problem for anybody that wants to use Eclipse with UMS. It has never been like this before, I've always used Eclipse, so this is a relatively recent regression. I also fail to see the point in removing the configuration, this particular part of the POM (that was clearer, eg?) is ONLY read by Eclipse so it has no impact on anything that isn't Eclipse. As such, it has no negative consequences that I can think of, so there should be no reason to remove it. Maybe you can create your first GitHub issue trying to get this fixed?
Regarding the "Debug Configuration" I wasn't thinking that you should figure it out yourself - I just didn't see any point in trying to explain it until the other error was resolved. Creating one is quite simple:
Select: Run -> Debug Configurations...
A new window will appear. Click the "New launch configuration" icon (upper left). Give the configuration a name, for example "UMS trace". Select "ums" (or whatever the project was imported as) under "project", and fill in "net.pms.PMS" under "Main class". In addition I find it useful to always run it in "trace mode" from Eclipse, and to achieve this, switch to the next tab "Arguments" and fill in "trace" under "Program arguments". That's it really, the rest of the settings can stay at their default values. You can go to the "JRE" tab and just make sure that a valid JDK is selected as "Runtime JRE". Once this is done, click the "Debug" button (bottom right) and it will save the configuration and start UMS.
Once this is working, you can simply press "F11" whenever you want to start the last debug configuration. That means that as long as you haven't created/chosen another one, "F11" will start UMS.
There's a couple of things you should do before you try to run UMS though, and that is to make sure all the Maven dependencies has been downloaded. If you haven't seen it in the documentation, you must first install "external dependencies". It is described what command to use in the beginning of the POM. Once that's done, you should run "mvn package" from a command line window while "being" in the "UniversalMediaServer" folder. It will probably take a while the first time, as Maven will download stuff from all over the Internet the first time you run it. Maven creates it's own cache in your Windows "home" folder under ".m2", so it will only be this slow the very first time.
Once all this is in place, you should be ready to start UMS from within Eclipse. That is very useful, both because it means that you can immediately test any changes you make to the code, and because you can set breakpoints in the code which allows you to inspect exactly what happens when the code in running, step by step.
With the project being imported, you should already see all the "packages" in the explorer on the left. Java "packages" are somewhat similar to folders in a file system (and they are in fact represented as folders in the repository). It's mostly a way to try to organize all the code files, although it also has some consequences for what access classes have to each other. So, by browsing into the "packages", you can find all the classes containing the code itself. Enjoy
), it's hard to understand a piece of code until you understand the logic. If the person who wrote it used descriptive names, was tidy and potentially commented where things weren't obvious, it might not be so difficult. Most of the time however, this isn't the case.About the m2e error, what you need to do is to paste the text that was removed in the commit I linked to, in the same location in porn.xml where it was removed. That is tiresome though, as you must do that every time you check out a commit. A better solution would be if the UMS devs would fix it. This isn't a problem only for you, this is a problem for anybody that wants to use Eclipse with UMS. It has never been like this before, I've always used Eclipse, so this is a relatively recent regression. I also fail to see the point in removing the configuration, this particular part of the POM (that was clearer, eg?) is ONLY read by Eclipse so it has no impact on anything that isn't Eclipse. As such, it has no negative consequences that I can think of, so there should be no reason to remove it. Maybe you can create your first GitHub issue trying to get this fixed?
Regarding the "Debug Configuration" I wasn't thinking that you should figure it out yourself - I just didn't see any point in trying to explain it until the other error was resolved. Creating one is quite simple:
Select: Run -> Debug Configurations...
A new window will appear. Click the "New launch configuration" icon (upper left). Give the configuration a name, for example "UMS trace". Select "ums" (or whatever the project was imported as) under "project", and fill in "net.pms.PMS" under "Main class". In addition I find it useful to always run it in "trace mode" from Eclipse, and to achieve this, switch to the next tab "Arguments" and fill in "trace" under "Program arguments". That's it really, the rest of the settings can stay at their default values. You can go to the "JRE" tab and just make sure that a valid JDK is selected as "Runtime JRE". Once this is done, click the "Debug" button (bottom right) and it will save the configuration and start UMS.
Once this is working, you can simply press "F11" whenever you want to start the last debug configuration. That means that as long as you haven't created/chosen another one, "F11" will start UMS.
There's a couple of things you should do before you try to run UMS though, and that is to make sure all the Maven dependencies has been downloaded. If you haven't seen it in the documentation, you must first install "external dependencies". It is described what command to use in the beginning of the POM. Once that's done, you should run "mvn package" from a command line window while "being" in the "UniversalMediaServer" folder. It will probably take a while the first time, as Maven will download stuff from all over the Internet the first time you run it. Maven creates it's own cache in your Windows "home" folder under ".m2", so it will only be this slow the very first time.
Once all this is in place, you should be ready to start UMS from within Eclipse. That is very useful, both because it means that you can immediately test any changes you make to the code, and because you can set breakpoints in the code which allows you to inspect exactly what happens when the code in running, step by step.
With the project being imported, you should already see all the "packages" in the explorer on the left. Java "packages" are somewhat similar to folders in a file system (and they are in fact represented as folders in the repository). It's mostly a way to try to organize all the code files, although it also has some consequences for what access classes have to each other. So, by browsing into the "packages", you can find all the classes containing the code itself. Enjoy
Re: GitHub and My computer problems
I lack to much knowledge on the electronics front to be able to judge your chances, but even with access to a hot air station I don't understand how you could both identify the acquire an identical one. That "world" doesn't exactly eager to inform about the details, and most information is simply unavailable to everyone but the "industry insiders".
I don't know if memtest(+) give you some addresses that might be possible to use to figure out which chip, but it sounds like way too much trouble to be worth it to me. Another question is if it in fact only is one bad chip. Chances are that even though maybe just one chip is currently failing, others might be just about to fail because they are probably from the same production batch and have experienced the same "wear".
In my experience, some RAM sticks are bad from the start, but those that are working properly for a while, are usually killed by excess heat. Most RAM sticks have very inefficient cooling, bad or no cooling fins, and rely on being surrounded by relatively cool air to remain in the "healthy temperature range". My "rule of thumb" is that the air inside the case shouldn't exceed 25 degrees, although that obviously isn't always possible. Anyway, I would take a look at the "cooling situation" for your RAM sticks and see what ability they have to get rid of heat. The fact that one has died might suggest that the conditions are less than ideal.
I don't know if memtest(+) give you some addresses that might be possible to use to figure out which chip, but it sounds like way too much trouble to be worth it to me. Another question is if it in fact only is one bad chip. Chances are that even though maybe just one chip is currently failing, others might be just about to fail because they are probably from the same production batch and have experienced the same "wear".
In my experience, some RAM sticks are bad from the start, but those that are working properly for a while, are usually killed by excess heat. Most RAM sticks have very inefficient cooling, bad or no cooling fins, and rely on being surrounded by relatively cool air to remain in the "healthy temperature range". My "rule of thumb" is that the air inside the case shouldn't exceed 25 degrees, although that obviously isn't always possible. Anyway, I would take a look at the "cooling situation" for your RAM sticks and see what ability they have to get rid of heat. The fact that one has died might suggest that the conditions are less than ideal.
Re: GitHub and My computer problems
If Louis Rossmann can do it anyone can, he'd be the first to admit that. I'm good at fixing things and messing round with electronics. Doing stuff at the scale Louis does is beyond me, but if I had the equipment I would love to give it a go.
As for getting a replacement chip it might not be that hard, they are generally made by a few manufactures and are not exclusive. My old laptop memory might use a similar chip so could harvest one from that. The important thing is making sure the part number matches. I can't tell what there are yet as the heatsink is glued on them so need a heatgun to remove it.
From the memtest it is the 23rd bit that is damaged, which I think is on the 2nd chip. just don't know which side of the Dimm that is on yet. will have to do more research.
I had noticed the heatsink has come off on one side a bit so that may have caused it to fail if it was overheating.
As for getting a replacement chip it might not be that hard, they are generally made by a few manufactures and are not exclusive. My old laptop memory might use a similar chip so could harvest one from that. The important thing is making sure the part number matches. I can't tell what there are yet as the heatsink is glued on them so need a heatgun to remove it.
From the memtest it is the 23rd bit that is damaged, which I think is on the 2nd chip. just don't know which side of the Dimm that is on yet. will have to do more research.
I had noticed the heatsink has come off on one side a bit so that may have caused it to fail if it was overheating.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: GitHub and My computer problems
I have no idea who Louis Rossmann is, but I'm not saying it can't be done - I'm just saying I'm not sure it's worth it. Believe me, such statements doesn't come easy from me, I'm known to try to fix things others generally regard as trash. I have a backhoe from 1961 for example, which had been abandoned in the woods for 17 years and I had to use a saw to "cut it out" of the bushes/branches. I got it going, got all the hydraulics going, got a little bit of brakes going and the steering on one of the front wheels, and drove it home some 40 km. Since that I've spent many, many hours on it, picked the engine apart twice, replaces absolutely all things rubber and bought old parts here and there. I've since used it for almost 10 years to clear snow in the winter, and for odd jobs that come up like replacing the water line to the house or "landscaping". And this is just one thing, I have 8 cars, 10 trucks/lorries, another tractor, an excavator, a boat and a motorbike. Only one car is newer than from 2000.. and my oldest truck is from 1944. The same goes for everything else, I have lots of old computer equipment, I've kept most electronics that's broken over the years "for parts" and the story goes on for pretty much everything I touchmik_s wrote: ↑Wed Jun 17, 2020 7:27 am If Louis Rossmann can do it anyone can, he'd be the first to admit that. I'm good at fixing things and messing round with electronics. Doing stuff at the scale Louis does is beyond me, but if I had the equipment I would love to give it a go.
As for getting a replacement chip it might not be that hard, they are generally made by a few manufactures and are not exclusive. My old laptop memory might use a similar chip so could harvest one from that. The important thing is making sure the part number matches. I can't tell what there are yet as the heatsink is glued on them so need a heatgun to remove it.
So, after spending many years "wasting" a lot of time repairing old stuff, I've finally started to realize that not everything is worth it. I don't actually believe it, I mean, most things should and could be repaired, but the capitalists have done such a great job at going after everything that makes repair possible that I've just had to realize that I can spend several lifetimes trying to "outsmart" them, but it doesn't actually give me much in return. The only way this can change is if most people realize how wrong and wasteful the current practices are, so that all the secrecy, special tools and designs that "break if opened" could be stopped.
So, if you have a proper hot air station and know how to use it, it can be done. What I'm doubtful of if is worth it is the time spent figuring out exactly what is broken and where to get a replacement. I'm aware that it's mostly all branding/faking that goes these days, and that within most areas, a very few manufacturers are actually supplying everything - while keeping the public "in the dark" about the lack of competition of choice we really have. I do know that they often go a long way to "hide" the link to the original manufacturer, exactly to prevent people from getting replacement parts from the source instead of buying new stuff. In addition, many deals have been made making sure that the consumer doesn't have access to buy these parts even if they managed to identify it correctly.
But, I could be wrong. It might turn out to not be to bad for you, but my "alarm bells" goes off telling me: This is the kind of project you should steer well clear of
I don't get the "23rd bit" thing. There are billions of bits in a RAM stick, so I don't quite understand how that information can be mapped to a specific chip.
That might very well have helped killing it yes, especially if the air temperature inside the case is generally high.
Re: GitHub and My computer problems
You might like to watch some of Louis's stuff. Started out as an audio tech at a recording studio end ended up fixing a lot of stuff himself when didn't have time to get things "professionally" repaired. He needed a Macbook for something but couldn't afford to buy a new one so bought a broken one off ebay and figured out how to fix it himself. once he had finished with it he sold it on for $200 profit, it ended up being such an easy fix he tried getting another one and things grew from that. All self taught. Now he has a store in New York with 14+ employees and fights for the right to repair. He calls out the BS from companies like Apple and shows how to fix their devices.
I much rather try and fix something myself. My old plasma TV died after a power cut due to a surge. Would have cost £100's to get sent away to be fixed so had a go myself. It had blew the chopper transistor and a few other protection components which in all cost about £10 to replace. I gave it to my nephew 7 years ago and it still works.
for the RAM, I guess it is the 23rd data line. I converted the faulty data to binary and compared them and it was the 23rd digit was wrong. might not be correct way of doing it but gives a guide without buying an expensive tester and it appears to be the one not in contact with the heatsink. This is a general guide but only shows a single sided DIMM. There is no real downside to trying, If it don't work then I have not lost anything.
Anyway I managed to get UMS to run in Eclipse now so just need the fix to use the latest code.
I'm thinking of trying to do something with the GUI to do conf's. Any ideas on where to start? Is there any sort of GUI editors for java?
I much rather try and fix something myself. My old plasma TV died after a power cut due to a surge. Would have cost £100's to get sent away to be fixed so had a go myself. It had blew the chopper transistor and a few other protection components which in all cost about £10 to replace. I gave it to my nephew 7 years ago and it still works.
for the RAM, I guess it is the 23rd data line. I converted the faulty data to binary and compared them and it was the 23rd digit was wrong. might not be correct way of doing it but gives a guide without buying an expensive tester and it appears to be the one not in contact with the heatsink. This is a general guide but only shows a single sided DIMM. There is no real downside to trying, If it don't work then I have not lost anything.
Anyway I managed to get UMS to run in Eclipse now so just need the fix to use the latest code.
I'm thinking of trying to do something with the GUI to do conf's. Any ideas on where to start? Is there any sort of GUI editors for java?
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
Re: GitHub and My computer problems
GUI things are quite hard to do in Java (there is a reason our GUI sucks!) and I suggest you look at easier tasks to get familiar with working with and submitting changes to the code. We have a label on GitHub "Good first issue" you might be interested in https://github.com/UniversalMediaServer ... st%20issue
Re: GitHub and My computer problems
It definitely sounds like Louis is "my kind of guy". I love people who put in the effort to work against the system that wants us to throw away everything. I guess I've just become somewhat disillusioned as I feel like they make it increasingly difficult an (almost) nobody is doing anything about it. I really love the "right to repair" concept, it should be in our constitution!
If you can find an identical chip from stuff you already have, and have access to the hot air station, I agree that there's no reason not to do it. I was thinking of going through all the hoops of actually acquiring an identical chip that works and isn't a Chinese imitation. In addition I would be slightly worried of minuscule "tin bridges" that could lead to short circuits that could kill your motherboard. I mean, when you heat up the stick, I would guess that the solder of the neighboring chips would also liquefy, and that it would be very easy to make a short somewhere that isn't easily detectable. Without a tester, you'd have to use your motherboard as the "tester", which could become much more expensive. But, if you're willing to risk this and the time and effort required, go for it I'll be rooting for you!
It feels great when you're able to fix something to give it new life. Not every operation ends up with that though
I replaced all the caps of the type that typically breaks on the HDMI board of my previous Onkyo, and it was some bitchy soldering on some of those caps, and it turned out not to do squat. My current Onkyo developed the same symptoms a couple of years later, and this model was covered by a "recall" for this problem so I sent it in. After communicating with the repair shop, it turned out that all they did to repair it was to reheat the "CPU chip" on the board. Onkyo had been forced to switch to lead-free solder (as everybody else), and they hadn't properly adjusted the solder temperature on the factory, so the bindings were weak and tended to fail after a while. Since the problem was "periodic" at first, and got gradually worse, my mind was kind of "locked in" on the caps. I didn't even consider it being a bad solder, but at the same time, fixing my "old" one was completely out of my reach as there's no way to do that without a hot air station.
If one chip was without contact with the heatsink, it would be a reasonable guess that it's the one who has died. I would still worry about potentially damaging the motherboard.
As SubJunk says, the GUI is probably the last thing you want to start with. It's a bitch to work with for several reasons, like the fact that the GUI framework itself is full of bugs and that Oracle abandoned all development on it years ago. The documentation also generally sucks, so for complicated stuff I usually have to study the code of the framework to figure out how to handle things. On top of that, the classes handling it in UMS is mostly a complete chaos.
Eclipse has tons and tons of extensions, and I know there used to be a graphical editor for this. I don't know if it's still available, because some projects become abandoned, typically the interest falls when the framework itself is abandoned, but it might still be there. It isn't that simple though. I've tried graphical GUI editors before, and they generally generate code very different from that a human would write. They generally can't "parse" human written code, only code they have themselves generated, so I'm pretty sure it would be impossible to "import" any of the existing GUI code into such an editor. If you wanted to make something completely from scratch, it might be viable, although the quality of the code generated often isn't very good.
To complicate things further, Java has no GUI support itself. It relies on toolkits/frameworks that handle GUI, and there are several to choose from, none of which is a good choice IMO.
First there was AWT. This was, as far as I understand, the "original" GUI framework for Java. It used the native GUI components in the OS'es, but since Java is cross-platform and the code should be generally reusable on all platforms, they simply skipped everything that wasn't available across all major OS'es. This is very little it turns out, making AWT more or less useless. The majority of the things you want to be able to do, simply aren't available.
Since that turned out to be a fiasco, they invented Swing. Instead of using the native GUI components, Swing does almost everything in Java. Swing has something called "Look and Feel" classes that tries to make the GUI mimic the native look of different systems. It's not identical though, but somewhat similar. This means that you can for example use the macOS LaF on Windows, if you so wish - and end up with a GUI looking like it belonged on a mac. This approach is slower, isn't properly "native", still doesn't support everything the native components do, and suffers from a number of inconsistencies and issues. UMS uses Swing. Swing could have been "half-decent" in my view, had Oracle not abandoned it years ago. But they did.
Both AWT and Swing was created and maintained by Sun/Oracle. When they abandoned Swing, they decided to abandon everything that resembled native "look", and created JavaFX. This toolkit doesn't even try to look like native GUI components, but has several "themes" that is completely unrelated to the OS it is being run on. As a "patch", they have made JavaFX stylable using CSS, so it is theoretically possible to customize components to look somewhat like the native components, and early on there were some attempts. From what I've seen these have since been abandoned. Oracle seems to have decided that desktop applications isn't really something they care about at all, and has also stopped JavaFX development after Java 8. The only good thing is that instead of letting it die a miserable death, they open-sourced it and has "given" it to the community to maintain and develop. So, there is still hope that JavaFX will have a future, although it's somewhat uncertain.
In addition to the Sun/Oracle frameworks, there is something called SWT, maintained by the Eclipse Foundation. This is obviously what Eclipse uses. SWT is in many ways superior, because it truly use the native GUI components for all (supported) OS'es, but it has one huge drawback. SWT code is NOT cross-platform, so you end up having to create all your GUI components one time for all environments you want to support. I did look into it once, but it seemed awfully complicated to get to play ball without causing a massive maintenance toll and extra work.
So, there you have it. Everything GUI is problematic in one way or another in Java, and it's all about figuring out what you think is the lesser evil. Not to mention that "switching" framework means rewriting all GUI code, making it very impractical to put it mildly. So, the conclusion is: Stay away from UMS GUI until you have some experience and is ready for some real frustration.
If you can find an identical chip from stuff you already have, and have access to the hot air station, I agree that there's no reason not to do it. I was thinking of going through all the hoops of actually acquiring an identical chip that works and isn't a Chinese imitation. In addition I would be slightly worried of minuscule "tin bridges" that could lead to short circuits that could kill your motherboard. I mean, when you heat up the stick, I would guess that the solder of the neighboring chips would also liquefy, and that it would be very easy to make a short somewhere that isn't easily detectable. Without a tester, you'd have to use your motherboard as the "tester", which could become much more expensive. But, if you're willing to risk this and the time and effort required, go for it
I'll be rooting for you!It feels great when you're able to fix something to give it new life. Not every operation ends up with that though
I replaced all the caps of the type that typically breaks on the HDMI board of my previous Onkyo, and it was some bitchy soldering on some of those caps, and it turned out not to do squat. My current Onkyo developed the same symptoms a couple of years later, and this model was covered by a "recall" for this problem so I sent it in. After communicating with the repair shop, it turned out that all they did to repair it was to reheat the "CPU chip" on the board. Onkyo had been forced to switch to lead-free solder (as everybody else), and they hadn't properly adjusted the solder temperature on the factory, so the bindings were weak and tended to fail after a while. Since the problem was "periodic" at first, and got gradually worse, my mind was kind of "locked in" on the caps. I didn't even consider it being a bad solder, but at the same time, fixing my "old" one was completely out of my reach as there's no way to do that without a hot air station.If one chip was without contact with the heatsink, it would be a reasonable guess that it's the one who has died. I would still worry about potentially damaging the motherboard.
As SubJunk says, the GUI is probably the last thing you want to start with. It's a bitch to work with for several reasons, like the fact that the GUI framework itself is full of bugs and that Oracle abandoned all development on it years ago. The documentation also generally sucks, so for complicated stuff I usually have to study the code of the framework to figure out how to handle things. On top of that, the classes handling it in UMS is mostly a complete chaos.
Eclipse has tons and tons of extensions, and I know there used to be a graphical editor for this. I don't know if it's still available, because some projects become abandoned, typically the interest falls when the framework itself is abandoned, but it might still be there. It isn't that simple though. I've tried graphical GUI editors before, and they generally generate code very different from that a human would write. They generally can't "parse" human written code, only code they have themselves generated, so I'm pretty sure it would be impossible to "import" any of the existing GUI code into such an editor. If you wanted to make something completely from scratch, it might be viable, although the quality of the code generated often isn't very good.
To complicate things further, Java has no GUI support itself. It relies on toolkits/frameworks that handle GUI, and there are several to choose from, none of which is a good choice IMO.
First there was AWT. This was, as far as I understand, the "original" GUI framework for Java. It used the native GUI components in the OS'es, but since Java is cross-platform and the code should be generally reusable on all platforms, they simply skipped everything that wasn't available across all major OS'es. This is very little it turns out, making AWT more or less useless. The majority of the things you want to be able to do, simply aren't available.
Since that turned out to be a fiasco, they invented Swing. Instead of using the native GUI components, Swing does almost everything in Java. Swing has something called "Look and Feel" classes that tries to make the GUI mimic the native look of different systems. It's not identical though, but somewhat similar. This means that you can for example use the macOS LaF on Windows, if you so wish - and end up with a GUI looking like it belonged on a mac. This approach is slower, isn't properly "native", still doesn't support everything the native components do, and suffers from a number of inconsistencies and issues. UMS uses Swing. Swing could have been "half-decent" in my view, had Oracle not abandoned it years ago. But they did.
Both AWT and Swing was created and maintained by Sun/Oracle. When they abandoned Swing, they decided to abandon everything that resembled native "look", and created JavaFX. This toolkit doesn't even try to look like native GUI components, but has several "themes" that is completely unrelated to the OS it is being run on. As a "patch", they have made JavaFX stylable using CSS, so it is theoretically possible to customize components to look somewhat like the native components, and early on there were some attempts. From what I've seen these have since been abandoned. Oracle seems to have decided that desktop applications isn't really something they care about at all, and has also stopped JavaFX development after Java 8. The only good thing is that instead of letting it die a miserable death, they open-sourced it and has "given" it to the community to maintain and develop. So, there is still hope that JavaFX will have a future, although it's somewhat uncertain.
In addition to the Sun/Oracle frameworks, there is something called SWT, maintained by the Eclipse Foundation. This is obviously what Eclipse uses. SWT is in many ways superior, because it truly use the native GUI components for all (supported) OS'es, but it has one huge drawback. SWT code is NOT cross-platform, so you end up having to create all your GUI components one time for all environments you want to support. I did look into it once, but it seemed awfully complicated to get to play ball without causing a massive maintenance toll and extra work.
So, there you have it. Everything GUI is problematic in one way or another in Java, and it's all about figuring out what you think is the lesser evil. Not to mention that "switching" framework means rewriting all GUI code, making it very impractical to put it mildly. So, the conclusion is: Stay away from UMS GUI until you have some experience and is ready for some real frustration.