Heyha ! I just came across a very odd issue/bug that somehow resolved by itself without knowing who or what was the culprit.

For context, YouTube doing his thing making nearly all public instances obsolete, I’m self-hosting a Piped instance in my homelab via Docker.

Everything is going smoothly, self-signed certs, traefik, accessible via Wireguard outside of my network, and and and !! LibreTube connects without any issues to my Piped instance on my Android phone and so does RiMusic.

However, in RiMusic when I was trying to access my synced Piped playlists, RiMusic went crazy and my playlist seemed to be in a query loop were I was unable to play any songs and was flickering alot.

  • Reboot the phone => Same behavior
  • Reboot the piped instance => Same behavior
  • Uninstall RiMusic/New docker piped instance => Same behavior
  • Flush everything from cache/playlist/configuration/data… => Same behavior

Nothing seems to resolve the issue software wise, next step check the logs (Interesting part):

My piped-nginx showed A HUGE amount of requests coming from my phone when accessing a Piped playlist:

"GET /playlists/d0e2c698-f3f4-435f-b2c9-96c6d3a88781 HTTP/1.1" 200 4161 "-" "ktor-client" "10.XXX.XXX.XXX"

Traefik also showed a lot of loadbalacing debug notifications something that never happens, because I’m the only user in my homelab setup !

My first though was that this is probably a RiMusic bug, but before reporting a report to GitHub, I did other debugging stuff.

  • Create an account and connect to a public piped instance
  • Create playlist/add some songs
  • Connect with RiMusic

The exact same behavior EXCEPT it stopped the loop after a few requests and made RiMusic usable again and was able to play my playlist without issues. Try again on my own instance but again, infinite loop, a lot of requests on Traefik and Piped-nginx. It even broke my Piped instance…

The only logical explanation is that the public piped instances have some request rate limiting (Yeah I know this is common practice and even mandatory on public instances). So here I go rate limiting my own requests to see if this could work as a temporary workaround while writing a GitHub bug report to RiMusic.

Adding some basic traefik labels just to give it a try:

labels:
  - "traefik.http.middlewares.test-ratelimit.ratelimit.average=10"
  - "traefik.http.middlewares.test-ratelimit.ratelimit.burst=20"

At first nothing happened but after a few docker compose -f down/up I was able to access my playlist from my own instance without any issues/bug/strangeness. Cool It works? So just out of curiosity I commented out the new traefik middelwares and restarted both container (Traefik/Piped). And … RiMusic playlist connected to my piped instance works without the ratelimite lines… Wait what ??

What just happend ? I have absolutely no idea… I don’t even know if the mentioned labels did anything… But everything works… No loading loop, No Traefik container overflown with loadblancer logs, No Piped-nginx with thousand request… It just vanished as it never existed in the first place.

I’m totally clueless except that somehow when accessing a playlist in private or public piped instance with RiMusic my phone went crazy with an infinite loop of api requests (Dunno if that’s the correct term :/). Here Am I with no idea what actually happend…

And yes my phone is Heavely debloated and firewalled (Magisk,rethinkDNS) so those are not unknown requests from the web or any open source application, whats so ever !


Sorry for the long write up I hope It’s readable and comprehensible. I just wanted to share my experience with you and If you also encountered some strange and inexplicable bug/issue that resolved by itself, feel free to share :).

PS: If someone has any good lead on what happened or some good insight where I should look next to get more out of this experience, I’m open to every good read !

  • Black616Angel@discuss.tchncs.de
    link
    fedilink
    arrow-up
    2
    ·
    2 days ago

    I habe another “magically solved itself” story with solution.

    When I leave my PC on for a long time without needing to access it, e.g. to make a backup or some long updates, I always lock it. This ensures that the monitor turns itself off.

    Or so I thought. Mostly I would only look at it, when accessing it again, since it faces away from the door. Then the screen was off.

    But sometimes when I didn’t want to use it, the screen was on. This really bothered me for a long time. When I wanted to use it, the screen was off and when I didn’t, the screen was on.

    Some day it just stopped happening. The screen was always off.

    Just last week I found out why this all happened.
    It was my phone. I have my mouse on the left side and always place my phone to the right. Except when not sitting at the desk. Then I put the phone on the left side which faces away from the wall. There it slightly shook the mouse thus activating the screen and gaslighting me. Last month I thoroughly cleaned my desk and now I don’t have to place the phone on my mousepad anymore.

  • JoeyJoeJoeJr@lemmy.ml
    link
    fedilink
    arrow-up
    2
    ·
    2 days ago

    In college, in my intro to Java class, I had a program I’d written that I was trying to show someone. Every time I ran it (in Eclipse) it crashed. It had worked earlier, but was then consistently crashing. Looked at the stacktrace, looked at the code… No issues I could spot. After quite a while of poking around, with the file reverted to its original state and still failing, I did a select all, cut, paste (into the same file), and it started working again.

  • prenatal_confusion@feddit.org
    link
    fedilink
    arrow-up
    2
    ·
    2 days ago

    Windows. Somehow I went away and was replaced by Linux.

    Problems have a tendency to solve themselves one way or the other. – some smart person