What I have always wanted from a phone since Android came out is what I had with my HTC Dream (the first android phone, slide out keyboard, trackball, oh god, I loved it). I had a super chunky extended battery which made it last multiple days on a single charge, or for someone such as myself made it last the full day. My current phone has a 5003mAh battery and is 8.9mm thick. I would happily take something that was 20mm thick to have all that space taken by a battery, which based on the dimensions of the battery is about 0.17Wh/mm^3. The remaining space should provide enough space for about 23500mAh which would bring the total to just under 29000mAh. At my current usage of charging twice a day from about 20% up to 100%, so around 4000mAh x2, and assuming we want to work between 20% and 80% for extended battery longevity, that would make about 17000mAh or just over 4 days of usage. That would be a delightfully chonky phone with the easy ability to keep the charge within the healthy range, not to mention the ability to have it stand on its side or upright without a stand in many cases.

Ah, sorry, missed that. So the missed alarm notification is happening way later, like hours later, than the alarm time? That sounds like the background process is being killed in some way. In Android when you set an alarm it uses the intent system to wake itself again later. If this is failing for your alarm app only then it could be an issue with the app, but this looks like the default clock application, is that correct? It looks like you maybe installed it from the play store but it may just be an update, so just checking.

That all said, if the clock is the only app with this problem then I would address it by replacing the app. If this is impacting other apps I can only think of a few ways that it could be caused but it should be fairly obviously problematic for other apps and solving that is beyond my understanding.

I would recommend trying another alarm clock app from a source you trust. I would install something from IzzyOnDroid on FDroid but your milage may vary.

Is it leaving a missed alarm notification?

Also, have you checked for battery optimisation for the clock app?

Do you have a smart watch? I have a client who had no notifications coming in sometimes but not others and it turned out it was his watch taking over notifications. Disabling it was done from the watch and took effect immediately.

I don’t know about videos but having a look at the OSI model is a good way to start. It covers the abstract framework for packetizing data including things like the distinction between hardware and software, envelope, encryption, application layer stuff, the whole shebang. The cool thing is by going hardware, network, application you can see where responsibility are and it helps you understand where things can go wrong.

If you are interested there are plenty of CCNA style courses available on the internet, licit and otherwise, and they go into more depth, and the same applies to RHCE/RHCSA material. The training for certifications like that covers what you want to know but also puts it in context, and again licit and otherwise sources are available.

It looks like it is downsampling the video or streaming after converting to another codec. Some codecs are fine for decoding on the server but the app may not support them so the server converts them. Some files are of higher quality than what the server is configured to deliver so it downsamples to stream it.

Check the configuration and look for anything to do with codecs, hardware decoding, streaming quality, and so on. It may also be on the app, so if you can access a different interface then test that to narrow down the issue.

Something I have found is missing from both of these suggestions as well as every podcast app on device is transcoding to speed up so it is not sped up on the fly. For a lot of phones and other devices the task of playing back at 2x speed is enough to demand a higher power state than what is required to play a sped up file. For efficiency doing a single pass of speeding up the audio then playing back at that speed would use less power during the playback phase, allowing you to download and speed up all of your podcasts at home while on charge then listen for long periods without completely killing the battery. I have checked with a few if the open source devs and this is not a feature they see utility for so nobody intends to make it.