Lemon Drop Hi-Res Moved to GitHub....

Search This thread

ShazamMan

Member
Jun 6, 2014
27
0
Okay dokay. SIM card was already removed from the start though, but not the microSD. I'll try that and re-do PARTITION DL one last time before I attempt a factory reset.
 

ShazamMan

Member
Jun 6, 2014
27
0
Yep, the phone is still plugged in after it restarts from LG UP. I doubt it's the cable, considering I can see both on the LG UP window and my phone's screen that files are being flashed during the PARTITION DL process.

And looks like the phone still hangs at the LG logo after I do PARTITION DL even without microSD, with everything checked or with laf unchecked.

I'm about to do a factory reset now. Fingers crossed.
 

ShazamMan

Member
Jun 6, 2014
27
0
Factory reset did the trick! I got the Android setup screen (as seen in the video) and can confirm I have H91510e on my H910.

Time to resume the root guide now.

But wow, I might be the first person who got into this issue despite following everything correctly! Thanks dude, your solution solved it!
 

ShazamMan

Member
Jun 6, 2014
27
0
Hmmm. I opened two CMD windows as instructed. I ran the dirtysanta command but nothing shows up afterwards. Is this normal? Could I proceed to run STEP1.BAT now?

Screenshot1.jpg


My device is detected, as seen in the above screenshot.

I put the contents of h910_root_pkg.zip in the platform-tools folder so I can run my adb commands from there. Looks like this:

Screenshot2.jpg


By the way, I swapped h910_root_pkg.zip's TWRP 3.0.2.1 for TWRP 3.3.1-0 and edited STEP3.bat to flash TWRP 3.3.1-0.

Edit: Yes, I did install ADB Installer file (adb-setup-1.4.2.exe) from the guide. But I also downloaded the platform-tools v4.55 for Windows. I put contents of h910_root_pkg.zip in that folder.
 
Last edited:

ShazamMan

Member
Jun 6, 2014
27
0
Never mind, I got a different ADB installer and got to STEP3.BAT.

Phone rebooted into bootloader (small text, FASTBOOT MODE).

However, I'm getting <waiting for device>. Any idea? All drivers installed.

Screenshot3.jpg
 

ShazamMan

Member
Jun 6, 2014
27
0
Okay, I found this comment:

screenshot4.jpg

This user is right because I'm getting this:

screenshot5.jpg


My LG driver is the latest from LG website (4.8.0). I'm trying to reinstall 4.2.0, but:

screenshot6.jpg


I'm in FASTBOOT now. Could I unplug the USB cable and put it back, then run STEP3.BAT? Maybe the driver will get detected. If not, how could I uninstall Driver 4.8.0 from the computer?

EDIT: Uninstalled Driver 4.8.0 with CCleaner. Reinstalled Driver 4.2.0 but still getting <waiting for device> after STEP3.BAT. Again, should I unplug the USB cable and put it back at this stage whilst my phone is in fastboot?
 
Last edited:

ShazamMan

Member
Jun 6, 2014
27
0
Right-clicked on the Android icon in Device Manager and uninstalled it. Now remove the cable and plug it back while still in fastboot, correct?
 

ShazamMan

Member
Jun 6, 2014
27
0
The installer from that fastboot access guide solved it! When I re-plugged in the phone, the Android icon in Device Manager disappeared. Now I have TWRP 3.1.1-0 on my screen!

Time to do some wiping and formating, rebooting in TWRP and then flashing H910_20g_Oreo_full_rooted.zip and Auto_Debloat_H910_20g_only_v9.1_flashable.zip in that order.
 

ShazamMan

Member
Jun 6, 2014
27
0
Flashed them both (followed your guide), but after rebooting the system (with some weird visuals), I see the Secure Start-Up (25/30 attempts remaining) screen again. Did I miss something?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 10
    Lemon Drop Has Moved to GitHub.
    Due to Bully's on XDA.


    4
    Eh i don't mind, just don't go around spreading misinformation about this chip, since all the android-side changes have to pass through the kernel driver. (i can edit messages too, which is nice)

    In any case, we (and Lineage) are here to help in case you need some pointers in the future about things you can implement into your android projects, and also open to contributions should you want to share any valid improvements.
    4
    Vbat has absolutely nothing to do with the dac, nor does the dac care about battery. It either gets the power or doesn't. Refer to the codec driver and kernel power subsystems (in which you'll find nothing because the dac doesn't care).

    Also, are we going to keep pushing the "sabotage" theory? I explained what the true-native-path is for with references to the audio hal. Refer to my last set of posts.

    This mod is pushing some serious misinformation to users.

    A. The dac is NOT programmed by factory to run on "1 of the 4 dacs", that's not how it works in software or electrically.

    B. The dac is not mono by default, and never has been, so I'm not entirely sure where this idea came from.

    C. The dac does not have 92k+ channels; it has 2, as per the documentation.

    D. Burn in? On a solid state chip? Unless you're testing chip stability, electrical property changes? That doesn't happen (and if it does happen, your chip has just failed the test).

    I also worry about the audio side stability of the users using this mod as I've already seen backend errors. A user might hit an edge case where audio could just be messed up. Without adequate testing, this is very likely to happen eventually.

    In short, stop pushing misinformation, most of which is proven to be incorrect by the es9218xx documentation that can be found online and audio hal sources.
    Another Dev here just thought I'd add on. If anything the mods changes will actually increase power consumption slightly due to the backend faults. Additionally @Darnrain1 you seem to missunderstand what a "QuadDAC" is. A QuadDAC is not 4 individual DACs, it is instead a set of sub-DACs (Source). Audio is routed through each sub DAC to improve noise performance. You have NOT "reprogrammed" anything all you have done is add useless lines to mixer files which actually make performance worse and claiming to have made any kind of real improvement is utterly disrespectful to people like @xxseva44 who have spent weeks making legitimate imrpovements to the DAC experience.
    4
    Welcome to v150.3
    My ears are vibrating right now, so that’s now a thing. I used my advanced Linux computer skills again to improve the audio quality a lot. Vbat = battery voltage, it was all messed up. The QuadDAC must know how much battery power you have left, because the DAC can suck up battery power like there is no tomorrow. I fixed a small issue with True Native Mode.

    I have always known without an absolute doubt in my mind, that someone deliberately sabotaged the mixer_paths file. I was always asking myself, now what did they sabotage this time? I went in there with a mind set, someone sabotaged the mixer_paths file, and I need to fix it. It was like a treasure hunt to me, I had some of the most fun in my entire life, trying to locate and fix what they sabotaged. So with trial, error, logic, and my advanced Linux computer skills and the knowledge of knowing that someone deliberately sabotaged the mixer_paths file, is how I have successfully converted my Lgv20 into an adequate, Hi-Res Music Player.

    Enjoy everyone...
    Vbat has absolutely nothing to do with the dac, nor does the dac care about battery. It either gets the power or doesn't. Refer to the codec driver and kernel power subsystems (in which you'll find nothing because the dac doesn't care).

    Also, are we going to keep pushing the "sabotage" theory? I explained what the true-native-path is for with references to the audio hal. Refer to my last set of posts.

    This mod is pushing some serious misinformation to users.

    A. The dac is NOT programmed by factory to run on "1 of the 4 dacs", that's not how it works in software or electrically.

    B. The dac is not mono by default, and never has been, so I'm not entirely sure where this idea came from.

    C. The dac does not have 92k+ channels; it has 2, as per the documentation.

    D. Burn in? On a solid state chip? Unless you're testing chip stability, electrical property changes? That doesn't happen (and if it does happen, your chip has just failed the test).

    I also worry about the audio side stability of the users using this mod as I've already seen backend errors. A user might hit an edge case where audio could just be messed up. Without adequate testing, this is very likely going to happen eventually.

    In short, stop pushing misinformation, most of which is proven to be incorrect by the es9218xx documentation that can be found online and audio hal sources.