Yeeah that theme still not in production, something I working on the side 😅
Project: RustedWax on GitHub
Website: RustedWax.com
One of the things I have learned while generating the code for RustedWax , is that making an Android application work is one thing, but making it work correctly under different circumstances is a completely different story, especially when we are talking about an application that needs to follow what you are watching or listening to without constantly asking for your attention, just running in the back doing its thing althogh in the future the app will give users more reasons to interact through it, no its nots blog posts. RustedWax was created with a very simple purpose, to Scrobble YouTube and YouTube Music content directly to Hive and make that activity available through https://Scrobble.life, but I realized that Android, browsers and media applications don't always behave as expected. That is exactly why I decided to concentrate this development cycle on reliability rather than adding more features, I find weird using the development word since I'm not a developer just an IT. Gettin back on track, I don't believe people should have to constantly check whether their music is being scrobbled correctly or manually restart services when something goes wrong. I have been keeping everything I work on Github and there are four recent important issues created, some bugs and other enhancements, in this update: #9 , #3 , #15 and #41 . Some might look like small corrections, but once you understand how they affect someone who uses RustedWax every day, they become much more important than they initially seem to be.
What Happens When Your Internet Connection Disappears?
One of the most interesting problems came from something that happens to me quite often while traveling through the subway the past two weeks that my electric scooter was waiting for parts. I normally listen to music using Brave Browser because it allows YouTube to continue playing in the background without a Yt premium account, thats something Brave does itself no tricks, and during the ride the mobile connection becomes unstable or disappears completely. Normally, YouTube simply stops playing and waits until the connection returns, nothing unusual there. I discovered that RustedWax wasn't always recognizing that the video had stopped making progress but instead it continued counting playback time even though the music wasn't actually playing, thats a big, not one affects the core function under perfect cincunstances but still a bug.
Imagine that you start listening to a five- minute song, but your connection disappears after the first minute, YouTube stops because there is no more data available but RustedWax continues believing that you are listening. During the original incident, the video was around 10% complete while RustedWax had already counted approximately 25%, so there was clearly something wrong. The thing is that for the most part Hive is written in ink and even if there was a chance to update the record I would not want that, just have RustedWax always verify before scrobble into Hive.
What made this situation worse was what happened when the internet connection returned, instead of recognizing that the same video had resumed, RustedWax could treat it as a new session, starting the progress counter from zero again. This could produce duplicate entries under History or Not Logged, and potentially record a song that was never actually played long enough. From the user's perspective everything looked normal because Brave simply continued playing the music but behind the scenes RustedWax had lost track of what was happening.
The correction introduced through Issue #9 makes RustedWax more careful about recognizing actual playback progress instead of simply trusting how much time has passed. When the video stops, progress under the Now page stops increasing and when the connection returns, the same video can continue its existing session instead of starting another one. This was physically tested on the Galaxy A36, Galaxy A12, Lenovo M9 and Galaxy S24, recently Im getting access to more devices to test with, wasnt easy in this case but manage to do it with all them under real network interruptions, including outages long enough to have incorrectly scrobbles and still RustedWax did the right thing, that was identify when Brave stops and not necessarly because you click on stop, it identify when the video stals and then resume when it needs too, although there still a window of 15 min and after that it just drops the Media Session, its not healthy to hold it for ever. I particularly like this improvement because mobile internet is not perfect. People travel through tunnels, move between Wifi and cellular networks or simply experience temporary outages. None of those situations should result in incorrect Scrobbles. At the end, the expected behavior is quite simple: if the music stops, RustedWax should stop counting, and when the music continues, RustedWax should continue with it.
YouTube Shorts and a Setting That Should Just Work
YouTube Shorts have been one of the more complicated parts of RustedWax development because their playback behavior is quite different from regular YouTube videos, users can move between Shorts very quickly, sometimes watching only a few seconds before moving to the next one and is something Im still not sure if its worth Scrobbling, some might think it would help because how many times have you seen a short on Yt, a TikTok or a Reel on IG and you trying to find the damn thing, but still they are disable from default, RustedWax includes a Disable Shorts option, allowing users to decide whether they want this type of content included in their history or not, part of the ideology is to let users decide and not exclude functions of a platform just because I dont want them. The problem discovered in Issue #3 was that the setting didn't behave consistently, for example when Disable Shorts was enabled, shorts on Yt App would not be scrobble but Shorts played through Brave Browser could still be scrobbled. From a user's perspective, that makes little sense, if I specifically tell RustedWax that I don't want Shorts included in my history, I expect that preference to apply regardless of which supported application I use.
But there was another problem, and I consider this one more serious because it affected regular music playback. Changing Disable Shorts while listening to a normal song could interrupt the current session, incorrectly move the song to Not Logged and sometimes leave scrobbling unable to continue. To restore normal operation, I had to manually turn certain observation services off and back on inside RustedWax , consider if you never watch shorts would never find out or if you have Yt Premium you would never find out. Now imagine an ordinary user encountering that problem without knowing those settings even exist, they could spend hours listening to music, assuming everything was working, only to discover later that nothing was Scrobble making the app look like its broken.
This was exactly the kind of behavior I wanted to eliminate. A simple preference should not interfere with an unrelated part of the application and the correction makes Disable Shorts work consistently across supported playback no matter if you using Brave or Yt App, while allowing normal videos to continue uninterrupted, without forcing users to restart observation services. I think this improvement is also important because not everybody uses YouTube in the same way, I even met someone for the first time that has multiple accounts to use Yt just because he hates the algo, same as I do. Some people mainly listen to music, others watch long videos and others spend a lot of time doom scrolling Shorts. There is no reason to force everyone into the same behavior, but when an application offers a preference, that preference needs to be reliable. Otherwise, it becomes just another switch in Settings that users eventually stop trusting.
Closing a Video Should Actually Mean Closing It
Issue #15 deals with another YouTube Shorts problem, this time involving Picture in Picture, another damn weird situation that I know most people wont face or even notice but what can I say I once had the chance to do Software Quality Control and thats PTSD kicking in, I dont only use my App but try to brake it everytime I can. The hell ish small floating video window that allows you to continue watching something while using another application, that was a tough one to keep under RustedWax leach, the App already supports this type of playback, including pausing and resuming, but a very particular sequence exposed an unexpected problem.
Imagine that you are watching a Short, move it into PiP , pause it and eventually close that window because you are finished watching. RustedWax recognizes that the session has ended and processes the video normally but YouTube can remain running in the background or just keep the same short the next time you open the Yt App instead of going to the Home page, even worst for RustedWax at that time remembering the exact Short and its previous position even though you explicitly dismissed the floating window. The problem appeared when returning to YouTube and pressing Play on that same video because RustedWax would recognize it again and start another session for content that had already been finalized, potentially creating duplicate entries or leaving another session that didn't finish correctly. I know I know its another very specific situation, but the application needs clear rules about when a listening session starts and ends, especially when that information can eventually reach Hive.
The solution was to establish a simple rule: when the user dismisses the PiP window, that Short's session is finished. It doesn't matter that YouTube is still keeping the same video loaded in the background, if you return and play that exact same Short, RustedWax won't immediately create another session for it. Once you move to a different Short then it start the new session, same as when a regular video ends and you got it in loop, it wont create duplicate entries or even start a new session just because the video play more than once, so I thought it should do he same for shorts.
There is a small trade off here because the resumed portion of that dismissed Short won't be counted as another listening session, but I prefer this behavior because it is predictable and avoids duplicates. Pausing and resuming while PiP remains open still works normally; only dismissing the window with the tiny X to the top right of the picture in picture video creates the definitive ending. Sometimes the best solution is not the one that tries to cover every possible combination, but the one that follows a simple rule consistently, no duplicates.
Making Sure Your History Stays Where It Belongs
While the previous three issues concentrate on detecting and measuring playback correctly, Issue #41 addresses something equally important: what happens to the information RustedWax has already collected and I know some might say well it doesnt matter because its already written to Hive but I see RustedWax becoming way more than just a Scrobbler / Snaps client for Hive, I got some plans that will unfold latter during the year since this App is very far away from been done.
Android applications are not guaranteed to remain running forever, there are cases where the operating system can close them to recover memory, users can restart their phones and application updates can interrupt normal activity. We had already experienced a situation where History and Not Logged information disappeared, which led to an earlier correction under Issue #3 1. That fix introduced persistence so records could survive when Android terminated the application, but as RustedWax continued growing, especially with Snaps and additional social features, it became clear that we needed a better way to organize everything stored locally, it wont do all the data but at least retain 50 Scrobble, 50 Not Logged and 50 Snaps with its comments. As much as I like blockchain we got to admit no WEB2 users is going to wait for confirmations and I think this is something the app has to take care in the background, dont matter if its a Scrobble, Snap, Comment, Like, it all has to happen right away at least in the eyes of the user and IF there is some sort of problem then a proper notification comes up.
That is where Issue #41 comes in, introducing a structured local database to manage information such as History, Not Logged, Snap drafts, Snaps, Comments and Notification. Now, before this sounds like another technical change that only developers should care about, consider a simple example. You listen to music during the morning, create a Snap draft while having lunch and later restart your phone, you wanted to put out a few Snaps out of this sick track and when you open RustedWax again, you expect your previous activity still be there. Nobody wants to lose something they were writing simply because Android decided to close an application, yes you cant query the blockchain and recover the records but what if you are offline for sometime or there is also the problem you got to wait for the app to consult the blockchain to extract the information, I personally prefer to keep a small reliable record locally for performance, no user out of crypto will wait for things to confirm or verify, my idea for the app is to feel as any other app so people dont even know at first they using Hive, Hive just the infrasctructure not the product.
There is also the question of Hive accounts, if one person signs out and another account becomes active, RustedWax should not start displaying the previous user's History and retrieving all this data from the blockchain is not the fastest option at least nor for now, we know this from when nodes are having problems, on a daily bases we see how front ends perform a bit slow or dont refresh right away. The new database keeps those records separated while preserving the appropriate information for each account seperate, I know not many will use multiple accounts but I guess its a colateral result from implementing the local data base. Another important detail is that not everything RustedWax detects gets published to Hive. A song appearing under Not Logged, for example, may only exist locally on your phone, so losing that information could also mean losing the explanation of why a particular video wasn't scrobbled. Hive keeps only the confirmed public transactions, yes I could get this also into a json but I dont want to write irrelevant or logs to the blockchain.
I consider this one of those improvements that users will probably never notice directly, and ist not done yet since now Im falling into maintance and settings limitations to this local data base, that is the next implementation. People simply want their history to remain available, their drafts to survive interruptions and their accounts to display the correct information. Issue #41 has been completed, physically validated and merged into the project, although we fall into the same situation that just because it works doesnt mean its done or working the right way, when I say this I mean this still needs more details to work on and thats issue #56 that is not included on this report.
Reliability Before More Features
Looking at these four issues together, I think they represent something important about the direction RustedWax is taking. It would certainly be more entertaining to spend every session adding buttons, supporting new media services or expanding social features, especially now that Snaps are becoming a substantial part of the application, but if I want this app to be realiable and behave just as any other main stream app and still use blockchain in the back, none of that matters very much if the basic experience is unreliable. There is little value in having a beautiful interface if songs are being counted while playback is stalled, settings interrupt unrelated sessions or local information disappears unexpectedly.
Something else I want to emphasize is the testing process, the hell that sometimes this is and the damn time it takes, specially when you take the time to test some of them in multiple devices. I dont push fixes simply because the project compiled successfully and Claude or Codex say its all good. I take the time to actually test them and take for a day or two on my Galaxy A36 again trying to break the app or just try to push as much scrobbles I can going through all three apps Yt Music, Yt App and Yt on Brave browser, because that is where many of the problems originally appeared. Automated testing is important, but it cannot fully reproduce every strange interaction between Android, browsers, floating video windows and unstable mobile connections.
The three playback corrections were completed and included in the RustedWax v0.12.2 stability release, there still v 0.13 that includes some other fixes and features I will talk about on my next blog post. There is still more work ahead and from now on plan to start bloggin about it, now that the app is out there and has very few features this kind of post might be a good way to let others know about it and I expect actual usage to reveal situations I haven't considered yet. At the end, the objective remains the same as when I started RustedWax : let people enjoy their music and videos while the application takes care of scrobbling in the background.
These might look like small improvements individually, but together they make RustedWax more predictable and easier to trust. For me, that is what this development cycle is really about, not adding features just to increase a version number or make RustedWax a social network app because its not and it wont. RustedWax is media first, social second and blockchain last, take users already known content that they like and enjoy, take their interaction with that content, and put it on the blockchain, let users Snap from something they already watch, listen and like insteado of having users to come up with content, one last aspect I think makes the social aspect different is that there wont be a for you or Snaps feed but only what the user Snap about and the comments to that Snap. I know this blog post was a bit longer that I wanted to but I have taken a lot of time to build this app and will continue to do so, keep it opensource, consider this is still under development so its not near close perfect, its all I work on aside form my job, I have even stop posting on my main account 