Slingplayer Free for Phone - success! ===================================== With Claude Pro, I managed to successfully patch the Slingplayer Free for Phone to run without the need to login to Slingplayer servers (they are not workign anymore). This is actually the second attempt, much streamlined with less testing of nonviable paths. Claude did most of the work, I just prodded it with confirmed information and best guesses about the needs of the application. Since with all the probability I cannot distribute the APK (likely not even binary patch would be safe) for copyright reasons, I am putting here my conversation with Claude - this should be enough to recreate the process. I am actually impressed by the result. Slingplayer Free for Tablet works in exactly the same way, with a little quirk at least on my phone: under default DPI, the remote displays out of screen area and is unusable. I had to set up Minimum width (under Developer options) to something like 600 and then it works. Installation and use -------------------- You need at least Android 4 (since Slingboxes are increasingly retrocomputing stuff, this is actually a useful warning - I have an old Androind 3.2 tablet that I wanted to use as a dedicated Slingplayer, but no joy). On modern Android versions, you have to enable installation from unknown sources (Settings → Security → Unknown sources), and if present, also disable verification of applications (Settings → Developer options → Verify apps over USB). Read below how to get the patched APK. Then you *have to* use `adb` to install the package: `adb install --bypass-low-target-sdk-block slingplayer-2-1-14-patched-signed.apk` Android will pop up a window informing the apk is unsafe, you have to click on More details and then Install anyway. On the first run, it will display a lot of warnings that the app is not compatible with this Android. Just click on OK and continue. Allow location access and all other permissions. Then you have to agree to the EULA. An ad-like window appears, close it by tapping the close icon at the top right corner. Click on Connect, the app might complain that "Your Slingbox model does not support streaming to device", click OK and it will stream anyway. **IMPORTANT** One big caveat: after some heavy testing (rapid connecting & discconnecting), the Slingbox crashed and had to be power-cycled. I suspect something is wrong with kicking out stale users. This guess is however based solely on the fact that I was never aked to kick out the logged in user (something which happened in this situation in the happy past when the Slingmedia servers were working). I tried to instruct Claude to debug it a bit, but no success (my Slingbox is remote and power-cycling is not trivial). So far I switched to using non-admin password to see if this happens again. Create the APK -------------- First, install necessary packages (Claude will install them for you, if given enough permissions, but why waste the tokens): `# apt-get install binutils-arm-linux-gnueabi zipalign apksigner openjdk-21-jdk-headless apktool unzip android-sdk-platform-tools adb droidlysis` Now, get (from somewhere) the original slingplayer APK, version is probably not that important, but probably no harm using the latest version, like Slingplayer Free for Phone 2.1.14 or Slingplayer Free for Tablet 1.0.1. In the following, it is assumed the APK is called `slingplayer-2-1-14.apk` and is in the current directory. Fire claude and feed it the instructions below (marked with ❯) one by one. Do not forget to glance at the responses, to see if it is on the right track. ❯ Hi, we are going to try to decompile an old android application. Please see the file slingplayer-2-1-14.apk. it is an old sling player app that does not work anymore because the slingmedia servers are down and it requires login. However, I have been able to make an already installed package work by modifying a cached connection file, so there is hope. We need to bypass the login and force connection to a specified slingbox ip address. Listed 1 directory, ran 4 shell commands (ctrl+o to expand) ● We have network access. Let's grab jadx for readable Java source (much easier to analyze than raw smali), while apktool's smali output is ready as a fallback for editing. Ran 2 shell commands (ctrl+o to expand) ● Good, decompiled successfully (4 minor errors out of 5495 classes is normal). Let's explore the structure to find login/connection logic. Ran 2 shell commands (ctrl+o to expand) ● Now let's explore the source tree structure for the app's core logic, particularly login and connection/finder logic. Read 5 files, ran 11 shell commands (ctrl+o to expand) ● This confirms the app already supports direct-IP connect (bypassing finder ID discovery). Let's look at the full context in SpmStreamingFragment.java around line 540-590 to see how it decides connect-by-IP vs connect-by-finder, and how it's populated (from a Bundle/Intent — likely from a "connection cache" the user could feed). Read 1 file (ctrl+o to expand) ● This is very useful — the fragment has clear bundle keys like STREAMING_SLINGBOX_IP_ADDRESS, STREAMING_SLINGBOX_CONNECT_BY_FINDER, etc. Let's see the exact code block that builds _slingBoxIdentity from the bundle (around line 540-600), and find where this bundle gets populated (i.e., what caller passes these args, since that's likely tied to a directory/box-list selection screen, which is where the "cached connection" data originates). Read 6 files, ran 8 shell commands (ctrl+o to expand) ● I've mapped out the app's architecture enough to plan a concrete fix. Here's what I found: - The app's real box-control protocol is independent of the dead cloud login. SpmSlingBoxIdentity/SpmSlingBox (spmControl/SpmSlingBoxIdentity.java, spmSac/SpmSlingBox.java) both support a direct IP+port+password connect path (connectByFinderId = false), separate from the finder-ID/cloud path. - SpmStreamingFragment.startStreaming() (Fragments/SpmStreamingFragment.java:541) already contains full logic to start a stream straight from STREAMING_SLINGBOX_IP_ADDRESS + STREAMING_SLINGBOX_PORT + STREAMING_SLINGBOX_PASSWORD, no finder ID needed. - The only things standing in the way are SpmLoginFragment (blocks on dead SAC login server) and SpmDirectoryFragment (needs a SpmSlingBox object populated from cloud/LAN discovery). SpmSlingBox is a plain Parcelable POJO with a public PopulateFields(...) method — trivial to construct by hand with our own IP/password. - The activity flow (SpmMainActivity → Login → Directory → SpmMainFragment) passes a Bundle with IS_SLINGBOX_OBJECT/IS_SLINGBOX_SELECTED forward; if we short-circuit that at the activity level, we skip login and directory entirely. So a smali patch is very doable: hardcode a SpmSlingBox with your target IP/port/password and jump straight to streaming, never touching the dead SAC servers. Before I start patching, I need some specifics from you. ● User declined to answer questions ⎿  · How do you want the fix delivered? (Patched, resigned APK (Recommended) / Guidance to edit the already-installed app's data / Both) · What are the Slingbox connection details to hardcode? (I'll provide IP, port, admin password, model now / Make it user-editable instead) ● What would you like to clarify? ✻ Cooked for 3m 52s ❯ Please first look through the code (also java) for connections to slingmedia.com and sling.com domains and nuke them (replace with .invalid), the servers are down anyway. Ran 9 shell commands (ctrl+o to expand) ● Now let me do a full sweep of the smali tree directly (in case jadx missed anything due to its 4 decompile errors) and check other native/config resources. Ran 3 shell commands (ctrl+o to expand) ● All smali is clean now. Let's also check the non-slingmedia package's smali tree (smali/tv/, smali/a/, smali/crittercism/, smali/android/) and the second smali directory apktool sometimes creates for multidex, plus unknown/native assets for lingering domain refs. Ran 2 shell commands (ctrl+o to expand) ● These are all safe, unambiguous matches with no .com length-prefix constraints (plain text/XML). Let's patch them all. Ran 5 shell commands (ctrl+o to expand) ● JSON parses cleanly and there's a trailing VERSION 2.1.14 field after it that I must preserve untouched. Now let's redo the rewrite correctly, keeping everything except the length prefix and JSON body. Ran 1 shell command (ctrl+o to expand) ● 75 domain strings inside the bundled config JSON got nuked (zeus.sling.com, secure.sling.com, relay.sling.com, rubens.sling.com, epgsolr.sling.com, sparcs.sling.com, analytics.sling.com, hbt.sling.com, services*.sling.com, ms.sling.com, egi.sling.com, zeus.sling.com, etc.), and the length-prefixed framing (MDCONFIGDATA, VERSION trailer) was preserved correctly. Let's do a final whole-tree sweep to confirm nothing is left anywhere. Ran 1 shell command (ctrl+o to expand) ● Done. Summary of what got nuked across the extracted APK (apktool_out/, ready for apktool b once we get to rebuilding): Smali (code): - SpmReminderActivity (both Fragments and Activities variants) — http://sling.com/ - SpmSportsFragment + SpmViewerMetricsEventWrapper — epgsolr.sling.com - SBHelpActivity — iphone-help.slingmedia.com - SpmGalleryConstants — rubens.sling.com (x2), egi.sling.com - SpmLoggerService — 3 @slingmedia.com log-email addresses - SpmViewerMetricsConstants + SpmViewerMetricsRequest$Builder — analytics.sling.com (the constant got inlined into the Builder class too, had to patch both) Resources: - res/values*/strings.xml (en/ja/ko/pt) — sling.com/slingmedia.com mentions (Chromecast/SlingTV promo text, upgrade nag text) - res/layout/settings.xml — placeholder test@slingmedia.com - assets/eula/eula_en.html, eula_pt.html — www.slingmedia.com, legal@slingmedia.com - res/raw/res_config.mp3 — this one's the big one: it's actually a length-prefixed JSON config blob (fake .mp3 extension) bundled as the app's default server config. It had 75 separate *.sling.com endpoints (zeus.sling.com session/IAP/logout, secure.sling.com SAC login/tickets, relay.sling.com finder relay, rubens.sling.com/epgsolr.sling.com EPG, analytics.sling.com, hbt.sling.com, services*.sling.com, ms.sling.com, sparcs.sling.com). All replaced, and I recomputed the embedded byte-length header field so the custom framing (MDCONFIGDATA + trailing VERSION 2.1.14) stays valid. Full tree sweep now shows zero remaining sling.com/slingmedia.com references anywhere in apktool_out. One thing worth flagging: I deliberately left slingbox.com alone since you named only sling.com/slingmedia.com. But that same res_config.mp3 blob has real operational-looking endpoints on slingbox.com too (apollo.slingbox.com, mobilesupport.slingbox.com, sports-api.slingbox.com, setupservices.slingbox.com, etc.), plus it's the domain used in most of the user-facing help/error strings. Want those nuked to .invalid as well, or left as-is? ✻ Sautéed for 3m 42s ❯ Please nuke also slingbox.com. Ran 2 shell commands (ctrl+o to expand) ● All clean, unambiguous literal occurrences (interesting to note: intapollo.slingbox.com/qaapollo.slingbox.com — these are internal/QA endpoints for the Apollo box-setup flow, hardcoded and duplicated across several fragments as inlined constants). Let's patch all of these plus the resource files. Ran 1 shell command (ctrl+o to expand) ● Now the res_config.mp3 length-prefixed JSON blob, same procedure as before. Ran 1 shell command (ctrl+o to expand) ● 59 more endpoints nuked there (apollo.slingbox.com, mobilesupport.slingbox.com, sports-api.slingbox.com, setupservices.slingbox.com, images.slingbox.com, etc.). Final full-tree sweep to confirm everything across all three domain families is gone: Ran 1 shell command (ctrl+o to expand) ● All three dead-company domain families (sling.com, slingmedia.com, slingbox.com) are now fully nuked to .invalid across the entire extracted APK tree — smali code, all localized strings.xml, settings.xml, both EULA HTML files, and the bundled res_config.mp3 JSON config (134 endpoint strings replaced total, with the custom length-prefixed framing recomputed correctly both times). Nothing has been rebuilt into a .dex/APK yet — this is all still sitting in apktool_out/ as edited smali/resources. Ready to move on to the login-bypass/direct-IP-connect patch whenever you want, or to rebuild+sign this as-is first so you can confirm the domain nuking alone behaves as expected. ✻ Crunched for 31s ❯ Now please implement the direct IP connect, by creating a dialogue at the start of the application that asks for ip/server, port, slingbox type (Pro HD as the default) and the password and then connects directly to the IP. The slingbox type is important to specify, otherwise it won't connect. Read 2 files, listed 2 directories, ran 9 shell commands (ctrl+o to expand) ● Let me check for any .field/inner-class edge cases I need to be careful with, then write and assemble the new class standalone before merging it in. Ran 1 shell command (ctrl+o to expand) ● Now I'll write the complete replacement class. ● Write(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment. smali) ⎿  Added 288 lines, removed 2550 lines 2 .super Lcom/slingmedia/slingPlayer/Fragments/SpmBaseFragment; ... 2882 - return-void 620 + return-object v1 621 .end method ● I left a bogus leftover line in there (an invalid LinearLayout$LayoutParams field reference I don't actually use). Let me remove it before assembling. ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Removed 2 lines 237 238 invoke-direct {v2, v0}, Landroid/widget/LinearLayout;->(Landroid/content/Context;)V 239 240 - sget-object v3, Landroid/widget/LinearLayout$LayoutParams; -->MATCH_PARENT:Ljava/lang/Integer; 241 - 240 sget v3, Landroid/widget/LinearLayout;->VERTICAL:I 241 242 invoke-virtual {v2, v3}, Landroid/widget/LinearLayout;->se tOrientation(I)V ● Now let's validate this file assembles cleanly on its own before touching the rest of the flow. Read 1 file, ran 1 shell command (ctrl+o to expand) ● Now let me replace this whole method with the corrected register-safe version. ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Added 63 lines, removed 59 lines 54 55 # virtual methods 56 .method public onClick(Landroid/view/View;)V ... 227 .end method Ran 1 shell command (ctrl+o to expand) ● It assembled clean. Let's verify the output and also sanity-check the bytecode by disassembling it back and diffing against intent (quick smoke test). Ran 1 shell command (ctrl+o to expand) ● Now let's do the real end-to-end validation: rebuild the entire APK with apktool b, which will assemble the whole smali tree and recompile resources. Searched for 1 pattern, ran 3 shell commands (ctrl+o to expand) ● Let me verify this aapt issue is pre-existing (environment/tool incompatibility) rather than something our edits caused, by testing a rebuild of a pristine, unmodified decompile. Ran 3 shell commands (ctrl+o to expand) ● Good — there's a -a/--aapt flag. Let's try pointing it at the system aapt2 first (with --use-aapt2), and if that fails, try downloading a proper Google aapt binary matching this older SDK format. Ran 1 shell command (ctrl+o to expand) ● aapt2 works. Let's verify the pristine rebuild, then rebuild our actual edited project the same way. Ran 1 shell command (ctrl+o to expand) ● Before finalizing, I need to verify the native streaming engine doesn't have a hard dependency on the SAC engine's initialize() call that I'm now skipping. Let me check where the actual box-control engine gets initialized. Ran 3 shell commands (ctrl+o to expand) ● Let me do a final safety check — confirm nothing else in the app casts a SpmLoginFragment instance to the interfaces I dropped (ISacEventsNotifyUI, SpmApolloSetupListener.*). Ran 2 shell commands (ctrl+o to expand) ● The direct-IP-connect flow is implemented and validated end-to-end. Here's what changed and why it works: What I built: Rather than bolting a new dialog onto the existing flow, I gutted SpmLoginFragment in place (same class name/tag/newInstance() signature, so SpmMainActivity needs zero changes) and replaced its username/password SAC-login UI with a plain-code form (no new resources needed, so no aapt/resource-ID headaches): - IP/hostname field - Port field (defaults to 5001) - Slingbox type dropdown — all 18 product IDs the SDK recognizes (Classic, Pro, 1.5, AV, Tuner, 1.6, SModem, Solo, Pro HD ← preselected default, 922, Solo HD, Morpheus, eSlingbox, Iris, Rose, Saber, Intrepid, Apollo) - Admin password field - "Connect as admin" checkbox (checked by default — needed for full remote-control access) - Connect button On tap, it builds an SpmSlingBox via the SDK's own PopulateFields(...) with no finder ID (ucaID = null), which is what makes SpmStreamingUtil.getStreamingBundle() automatically take the direct IP/port connect path instead of the (dead) cloud finder-ID path — this is the exact mechanism the SDK already had for LAN-discovered boxes, we're just feeding it by hand. That result gets handed to SpmMainActivity in the same bundle shape a real successful login+box-selection would produce, so it walks straight into SpmMainFragment → SpmStreamingFragment → connects to your box directly. Login, the SAC cloud directory, and finder-ID lookup are never touched. I confirmed this is architecturally safe: the actual box-streaming engine (SpmControl/SpmStreamingSession) initializes itself independently the moment streaming starts — it has no dependency on the SAC login engine ever having run. Validation done: - Hand-assembled the new class standalone with smali — clean. - Full-project rebuild with apktool b — smali stage compiled clean across all ~5500 classes. - Hit a pre-existing environment snag: this sandbox's system aapt (Debian's old build) chokes on this app's resources.arsc — confirmed by reproducing the identical failure on a pristine, unmodified decompile, so it's not something our edits caused. Fixed by building with aapt2 instead (apktool b apktool_out -o out.apk -a /usr/bin/aapt2 --use-aapt2). - End-to-end rebuild of the fully edited project (domain-nuking + this new dialog) succeeded, producing a valid 24MB APK with an intact classes.dex. One thing to flag: I checked and nothing else in the app casts SpmLoginFragment to the interfaces I dropped (ISacEventsNotifyUI, SpmApolloSetupListener.*), so removing them is safe. The APK is unsigned at this point (a test build at /tmp/rebuild_test.apk, not saved anywhere permanent) — signing is the natural next step whenever you want it. Want me to sign it (with a new debug key, or one you provide) and produce an installable APK? ✻ Cooked for 15m 45s ❯ Sign it with a new debug key please. Searched for 1 pattern (ctrl+o to expand) ● All the tools are available. Let's rebuild fresh (to make sure we're signing the latest edits), generate a debug keystore, zipalign, and sign. Ran 1 shell command (ctrl+o to expand) ● Clean rebuild. Now generate a new debug keystore and sign. Ran 2 shell commands (ctrl+o to expand) ● Now sign it with apksigner. Ran 1 shell command (ctrl+o to expand) ● Signed successfully. Let's verify the signature and double-check the manifest matches expectations (min SDK, package name, no debuggable flag accidentally left on). Ran 1 shell command (ctrl+o to expand) ● Verifies cleanly with v1/v2/v3 signing schemes (good coverage for old-to-new Android versions given this targets minSdk 19). Ran 2 shell commands (ctrl+o to expand) ● Signed successfully: slingplayer-2-1-14-patched-signed.apk (24MB) — verifies clean under v1/v2/v3 signing schemes, package name (com.slingmedia.slingPlayerFreeApp), version (47 / 2.1.14), and min/target SDK (19/26) all unchanged from the original. Keystore: slingplayer-debug.keystore (alias slingplayer-debug, password android for both store and key — it's a throwaway debug cert, not meant to be secret). I kept it alongside the APK — hang onto it if you want to rebuild/update later, since re-signing with a different key would make Android treat it as a different app. One important heads-up: this has a brand-new signature, different from whatever originally signed your installed copy (Play Store or sideloaded). Android won't let you install over an existing app with a mismatched signature, so if you already have SlingPlayer installed — including that instance where you'd hand-edited the cached connection file — you'll need to uninstall it first before installing this one (that'll wipe its app data, but that's moot now since this build bypasses login/cache entirely via the new Connect dialog). Files are in the scratchpad at: /tmp/claude-1000/.... Want me to move the APK somewhere more permanent (e.g. your project directory /home/.../), or is scratchpad fine since you'll adb install from here? ✻ Sautéed for 1m 26s ❯ Yes, please move it to the project directory. Ran 1 shell command (ctrl+o to expand) ● Moved. In /home/.../2-1-14/ now: - slingplayer-2-1-14-patched-signed.apk — the patched, signed, ready-to-install build - slingplayer-2-1-14-patched-signed.apk.idsig — its v4 signature side-file (keep it next to the APK; some install paths use it) - slingplayer-debug.keystore — the signing key, for future rebuilds Ready to adb install slingplayer-2-1-14-patched-signed.apk (or sideload it directly) whenever you want to try it. Let me know if you hit anything on-device — happy to dig further if the connect dialog or the direct-IP session doesn't behave as expected. ✻ Cogitated for 6s ❯ Please make the server/port/password etc. persistent across application launches. Read 1 file (ctrl+o to expand) ● Let me confirm the exact SpmAppPreferenceStore method descriptors before editing, to avoid register/type mistakes. Ran 1 shell command (ctrl+o to expand) ● Confirmed. Now let's insert the persistence-save block into onClick. ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Added 28 lines 150 151 move-result v9 ... 183 invoke-direct {v10}, Lcom/slingmedia/slingPlayer/spmSac/Sp mSlingBox;->()V ● Now the load side in onCreateView — bump .locals and add the restore block before return-object v1. ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Added 1 line, removed 1 line 255 .end method ... entActivity; 261 ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Added 79 lines 647 .... 730 .end method ● Let me make the getPreferenceStore() owner consistent with how I called it in onClick (declaring class, not subclass) to remove any doubt. ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Fragments/SpmLoginFragment .smali) ⎿  Added 1 line, removed 1 line 647 ... 652 move-result-object v10 653 Ran 1 shell command (ctrl+o to expand) ● Clean assembly. Now let's do the full project rebuild to validate everything end-to-end, then re-sign with the same keystore so it can update the previously installed copy. Ran 1 shell command (ctrl+o to expand) ● Clean build. Now let's zipalign and sign it with the same keystore from before (so it can update the already-installed app rather than requiring another uninstall). Ran 1 shell command (ctrl+o to expand) ● Same certificate fingerprint as before (2026c2b7...), so this can install directly over the previous build without uninstalling. What changed: the Connect dialog now saves IP, port, Slingbox type, password, and the admin-checkbox state to the app's own SharedPreferences the moment you tap Connect, and pre-fills all five fields from those saved values the next time the dialog is shown — so after the first successful connect, relaunching the app has everything already filled in and you can just tap Connect again (or change only what's different, e.g. switching boxes). slingplayer-2-1-14-patched-signed.apk in /home/uzivatel/and/2-1-14/ is updated in place. ✻ Sautéed for 3m 33s ❯ Please look into the native SDK for connection attempts to *.sling.com and *.slingmedia.com and replace the domains with .inv Ran 4 shell commands (ctrl+o to expand) ● That's interesting — libspsdk.so already shows .inv domains, and its file timestamp (Sep 21) differs from all the other libs (Sep 17). This means someone already patched it outside this conversation. Let me get the full picture before touching anything. Ran 1 shell command (ctrl+o to expand) ● All three domain families (sling.com, slingmedia.com, slingbox.com) are already fully patched to .inv in libspsdk.so — 44 occurrences, zero remaining. Let me verify the patch is byte-clean (not corrupting the binary) and check every other library just to be thorough. Ran 2 shell commands (ctrl+o to expand) ● Let me verify whether the currently-shipped signed APK already includes this patched native library, or if it needs a rebuild to pick it up. Ran 1 shell command (ctrl+o to expand) ● Good news — there's nothing left to do here. I searched every native library (libspsdk.so, libslingnp.so, libslingdialclient.so, libacr.so, libas.so, libcurl.so, libcrypto.so, libssl.so, and the H264 decoder libs): - libspsdk.so is the only one that ever embedded domain strings, and it's already fully patched: all 44 occurrences across *.sling.com, *.slingmedia.com, and *.slingbox.com (analytics, services, secure/accounts, sparcs, relay, etc.) are already rewritten to .inv — e.g. http://analytics.sling.inv/analytics.gif, https://secure.sling.inv/slingaccounts/rest/..., http://relay.sling.inv/sms/rest/.... - I verified the patch is byte-clean: .com→.inv is length-preserving (4 chars either way), each string is still properly null-terminated with no overlap into neighboring strings, and the ELF header/dynamic section both check out as structurally intact. - Every other .so had zero hits to begin with. - I also confirmed the currently-shipped slingplayer-2-1-14-patched-signed.apk already bundles this exact patched libspsdk.so — so no rebuild is needed on that front either. One thing worth flagging: libspsdk.so's file timestamp (Sep 21) doesn't match the other libraries (Sep 17, from when we first decompiled), and none of my tool calls ever touched this file — so this patch was applied outside our conversation, presumably by you directly. Just wanted to surface that in case it wasn't you and this is unexpected — let me know if that's the case and I'll dig into what else might have touched the tree. ✻ Churned for 1m 57s ❯ OK, it was you in a parallel timeline, though I have no idea why it was not restored when rewinding the time. ● Ha, that explains it — conversation rewinds don't undo filesystem side effects, so the patched libspsdk.so stuck around from that branch. Good news either way: it's confirmed correct, verified byte-clean, and already baked into the signed APK, so there's nothing to reconcile. Everything's consistent and ready to go. ✻ Brewed for 8s ❯ Now please look at the SpmControlInternal.java:1156-1158. We never populate STREAMING_SLINGBOX_FINDER_ID, so it gets null every time, which is going to cause problems. Please look at SpmStreamingUtil.getStreamingBundle() and assign "MANUAL-" + ip identifier synthetic identifier to our slingbox. Read 2 files, ran 2 shell commands (ctrl+o to expand) ● Now let's see the :cond_7 block (the IP/port branch, where finder ID is absent). Ran 2 shell commands (ctrl+o to expand) ● Update(apktool_out/smali/com/slingmedia/slingPlayer/Streaming/SpmStreamingUtil .smali) ⎿  Added 22 lines 446 447 .line 65 ... 473 invoke-virtual {v9, v12, v11}, Landroid/os/Bundle;->putStr ing(Ljava/lang/String;Ljava/lang/String;)V Ran 1 shell command (ctrl+o to expand) ● Clean. Now the full project rebuild, zipalign, and re-sign with the same keystore. Ran 1 shell command (ctrl+o to expand) ● Clean build. Now zipalign and sign with the same keystore. Ran 1 shell command (ctrl+o to expand) ● Fixed and shipped. Same certificate fingerprint as before, so it'll install right over the existing copy. The bug: SpmStreamingUtil.getStreamingBundle() only ever put STREAMING_SLINGBOX_FINDER_ID into the bundle on the finder-ID connect path. On the direct-IP path (the one our dialog always uses, since we never set a finder ID on the SpmSlingBox), that key was simply never written — so SpmControlInternal.java:1156 reads it back as null and hands null straight into fetchSparcsData(). The fix: in the IP/port branch (:cond_7 in SpmStreamingUtil.smali), before the existing IP address/port/connect-by-finder=false puts, I now build "MANUAL-" + szIPAddress via a StringBuilder and putString it under STREAMING_SLINGBOX_FINDER_ID. So e.g. connecting to 192.168.1.50 now yields a finder ID of MANUAL-192.168.1.50 — non-null, unique per box, still leaves connect by finder id = false untouched so the actual connection still goes over IP/port as before. Validated the same way as the earlier changes: standalone smali assemble on the touched file, then a full apktool b project rebuild (clean), zipalign, and re-sign — all green. ✻ Cooked for 2m 17s