yashsingh1/xdaforums huggingface dataset:
[Nexus 7 (2013) General] oohyeah:
OK let me get something straight.

Obviously, the factory resetting that wiped out all internal storage (the original point of the thread) has nothing to do with TWRP, and I never said it did. On this point though, I'm surprised that it doesn't seem to be more well known that a factory reset would do wipe out all your data (did several searches and only found 'confirmations' that your internal SD data would be left untouched), though I'm glad that I know it now.

The suggestions on different ways to boot into recovery were helpful, though I believe that I would still have encountered the dead android, or would I not have?

What's certainly still not clear to me though is regarding the problem of not being able to boot into recovery and getting the dead android with the exclamation/triangle. After the first few replies, I expected to hear that this was NOT meant to be the case and that I did something wrong in the process or whatever.

However, what I seemed to get was that this is the expected behavior, and what I needed to have done was to "get rid of /system/etc/install-recovery.sh".

So let me ask these questions for clarification:

1. Is the dead android normal, given what I did/didn't do?

2. Is deleting /system/etc/install-recovery.sh part of the process of installing TWRP in order to be able to boot into recovery?

3. Would I also need to get rid of /system/etc/install-recovery.sh if using CWM?

(so far it doesn't seem to. After installing CWM I'm not getting the dead android and I didn't delete the install-recovery.sh).

Thanks. And just to be clear, I hope no one takes it the wrong way that I'm bashing TWRP or anything, because I"m not. Just been a long time user of CWM and this is the first time using TWRP and encountering the dead android.
[Nexus 7 (2013) General] khaytsus:
Dead android = stock recovery, so normal there.

When you flash a custom recovery on a stock ROM, there is a file, /system/etc/install-recovery.sh, or I actually prefer just renaming /system/recovery-from-boot.p, which will automatically verify your recovery image and restore it to stock if it doesn't match. So you must always remove this file, or the ROM will restore the stock recovery on boot.

TWRP makes it easy to remove either file by mounting /system in read-write mode and using its built-in file manager to remove it. You can do the same in CWM using adb.

As for point 3, yes, try to reboot into recovery again. If you didn't remove (either file), you'll find stock recovery again.
[Nexus 7 (2013) General] oohyeah:
Thanks, Khaytsus. I booted into recovery (long press power button, reboot menu, recovery), and it booted straight into CWM, like it always has with my other devices. (And to confirm, I have not even looked for the install-recovery.sh file, let alone removed or renamed it.)

So far it seems to me that TWRP requires removal of install-recovery.sh, whereas CWM does not, but this doesn't seem to be what you guys are telling me is supposed to be the case.
[Nexus 7 (2013) General] sfhub:
It really depends on what ordering you do your actions in.

/system/etc/install-recovery.sh doesn't exist on a stock factory shipped system.

It only gets put in place after you install an OTA. If you do all your upgrades using the factory images, you'll never encounter it.

What it does is during your boot process, it will check to see if your recovery is different than what it expects (ie stock). If so, it will install stock recovery by taking the stock kernel and patching it.

If any of the following are true, it will not overwrite your recovery:

/system/etc/install-recovery.sh is missing (or modified to not run as the original file)

/system/recovery-from-boot.p is missing

you are not running the stock kernel

The most common way for install-recovery.sh to be missing is you always used factory images.

The most common way for install-recovery.sh to be modified to not do the original function is if you installed SuperSU. It will overwrite install-recovery.sh with its own.

So in all the back and forth, it is quite possible you got rid of install-recovery.sh or had it modified simply by installing root.

If you then subsequently installed custom recovery, it would stay in place.

Previously you were installing TWRP and flashing it onto the tablet, but upon booting into android, install-recovery.sh realized it wasn't stock recovery, and overwrote TWRP with stock recovery.

That is why whenever you rebooted, you got fallen android (which is stock recovery)

If the way you installed cwm is to use "fastboot flash recovery cwm.img" then the only reason it is around is because something else you did got rid of or modified install-recovery.sh. cwm would be no more immune to install-recovery.sh than twrp was.
[Nexus 7 (2013) General] di11igaf:
Just to clarify, you didn't lose root. You just lost the supersu app, a root permission manager, because it was installed to your /data partition. The su binary was still in /system, all you would have had to do was install supersu from the market.
[Nexus 7 (2013) General] creaturemachine:
I'm not sure what else you were expecting from a "factory reset"
[Nexus 7 (2013) General] Skaziwu:
Did you read the thread? He explained his reason for expectation quite well.

I just started up on a Nexus 4, and was also surprised to see this. Coming from a Galaxy S2, the "sdcard" being left intact was pretty convenient when flashing from ROM to ROM. Albeit, leading to some messiness. When did Nexus change to this behavior?
[Nexus 7 (2013) General] sfhub:
Depending on which level you are looking at, it didn't really change the behavior, but rather how your data is organized.

Factory reset has always wiped out /data.

On older devices, they put the /sdcard in a separate partition and formatted fat32.

These are the ones that were surviving a factory reset.

On newer devices, the internal /sdcard is starting to migrate onto a directory in /data and the "sdard" you see is "virtual". Since it is on /data, when you wipe data, the virtual sdcard is also wiped.

Some recoveries try to simulate the previous behavior by doing a "rm" of every directory except the virtual sdard when you choose to wipe, instead of the erase/format that Android is doing.

The advantage of keeping the sdcard as a directory under /data is you don't need to decide how much space to split between the sdcard and your /data. Also permissions on files are more flexible being in an ext4 filesystem. Finally since everything is emulated and accessed via MTP, you don't need to unmount the filesystem, so your PC can access it.

There are also cons with this approach, but that is what Google is going with.
[Nexus 7 (2013) General] oohyeah:
Right, that makes sense. Thanks for that, sfhub.

It seems like the recoveries are leaving the /sdcard directory untouched, so the lesson for me is to never use Android to do the factory reset, but to use the recovery.

Regarding the install-recovery.sh point, thanks again for all the info, I've learned so much from this thread, esp from your input. I guess I must have done something else around the time I installed CWM which got rid of that file or something.
[Shield General] Jonbo298:
After getting all the initial setup done, it's seemingly ran great so far; considering the circumstances. Haven't had any errors besides some DNS thing I didn't get to read fully when it booted up Steam but did not have any impact on playability.
[Shield General] daethang:
DLL error

I keep getting an error that MSVCR120.dll is missing. I checked the windows\system32 folder and it wasn't there, so installed the Visual C++ redistributable package for Visual Studio 2012 and 2013 Preview. This added the DLL to the system32 folder, but still getting the same error after a reboot. Tried copying the DLL to the directory for Shield Proxy and it then gives me an error "The application was unable to start correctly (0xc000007b). Click ok to close the application.

Any ideas?

Thanks and thanks for putting this together!

Cheers!
[Shield General] cgutman:
I can't remember whether the 64-bit Visual C++ redistributable includes both 32-bit and 64-bit runtime dlls. The relay is built as a 32-bit program so it needs the 32-bit runtime even on a 64-bit machine.

For the next version, I'll build it with the runtime linked into the executable so people won't have to hunt down the runtime.
[Shield General] daethang:
Thanks - installed the 2013 32bit preview and it worked like a charm after. Will start testing the remote streaming now. Thanks for the quick pointer. Appreciate it!

Cheers
[Shield General] cgutman:
Cool, I updated the instructions to mention that the Visual C++ 2013 x86 runtime is required.
[Shield General] david419kr:
Oh, nice.

Since VPN method didn't work on my rig, I tried this one... and works great!

thanks a lot.
[Shield General] daethang:
Seems to be working here as well, although similar to VPN, streaming outside of my WIFI connection doesn't seem to work. The game will start and every once in a while I will see video start (more often though just a blank screen followed by a timeout). My home connection has 55 down and ~12 up, so I think the connection on that end is good. I have tried from multiple remote locations, but none of them have worked so far. Will do some speed tests on the remote connections to see if they are the cause. Splashtop seems to stream fine when on remote connection, so I dont think its a connection issue. One thing that works better on this solution is the PC actually shows as available, for some reason it does not when on VPN.
[Shield General] cgutman:
From what it sounds like, the MDNS relay is working fine and the router is definitely configured correctly because you get video sometimes. I assume you also see the message in the ShieldProxy.exe console: "Shield is now communicating with us on port XXXXX".

If I had to speculate, I'd say it's related to high packet loss. Shield streaming (both on the network and through my proxy) use UDP for the video stream and a PPTP VPN uses GRE packets which are both lossy protocols, while Splashtop uses TCP which retransmits lost packets. It may be that the ISP is doing some QoS stuff that's causing non-TCP packets to be dropped at a higher rate, but this is complete speculation.

The Shield pings the streaming PC and the streaming PC sends back video data, but if the pings aren't reaching the streaming PC or the video isn't reaching the Shield, you get the dreaded "Streaming failed due to network interference ... etc" message.

The upside is that we can better troubleshoot the issue based on the output from the Windows Shield proxy. If you could paste that here, I could take a look (remove the last 2 octets of the IP addresses, so 192.168.1.1 becomes 192.168.X.X). Also if you would post what ISP you're using and where you were trying to connect from (whichever ones you feel comfortable mentioning).
[Shield General] HobsonA:
I can't seem to get any of those ports open except 47989, even when I change my setup to be directly connected to my SB6141 modem. Port 5354 always appears closed and can't be accessed so I never can see my computer when I try connecting with the shield proxy app posted above.

Anyway to change the port to something other than 5354 or any idea why the port always appears closed even when connected from computer to modem?

Thanks

Edit: It seems only ports that are being listened to on netstat -an will appear as open to a port checker. Shouldn't there be something on that list listening for 5354 in order for Shield proxy to connect to that port?
[Shield General] cgutman:
Ports will appear closed even if the router is properly forwarding them to your PC, but the PC is blocking them. Check your Windows Firewall settings and make sure ShieldProxy.exe is allowed through for both public and private networks. I also found out the hard way that it won't always prompt you to allow for public networks if it's already allowed for private and vice versa.

I think it's normal for those other Shield Streaming ports to be closed until streaming actually starts, but 5354 should appear open while ShieldProxy.exe is running.

It is possible for me to (and I plan to) add some code to make the MDNS relay port configurable but I don't think that would solve your issue here.

EDIT: Also make sure you're testing 5354 (and other UDP ports) as UDP, not TCP. TCP 5354 is not the same as UDP 5354. In fact, you can host different services on the same ports on TCP and UDP at the same time.
[Shield General] HobsonA:
Ah good call out of my lack of attention to detail I forgot to run Shieldproxy.exe again after removing my router from the loop and rebooting everything. It appears to be working now. Unfortunately my Linksys E2000 with DD-WRT has been having major issues port forwarding but at least I know it's my router now and I can keep playing with it to get it working like I had to do with VPN.

Thanks!
[Shield General] cgutman:
v0.2 released

I've posted updated releases for Android and Windows on the GitHub projects. None of the changes in either version break compatibility with v0.1 so you can update them at separate times.

Android v0.2 Changelog:

- Fix several bugs preventing the "MDNS relay not running" warning from showing up consistently

- Tighten the check that determines whether the MDNS query will be forwarded

Windows v0.2 Changelog:

- Statically link to the VC++ runtime so installing the runtime isn't required anymore

- Tighten the check that determines whether the MDNS query will be forwarded
[Shield General] daethang:
I think you are right in regards to packet loss. I have Comcast at home, and have tried various providers (ATT LTE, ATT WIFI so far with this solution and VPN over some other WIFI networks). I will be testing it again in the next couple of days and will report back with the additional details requested. I have the ASUS NT-R66U router as well. Thanks for the reply and offer of assistance, really appreciated.

Cheers!
[Shield General] HobsonA:
Finally had some time to play with this more than some quick tests. This seems to run so much smoother than my old VPN configuration.

I don't know if anyone else has experienced with this but even though it's running like almost perfectly smooth sometimes the connection just completely drops. VPN would have big lag spikes but would rarely drop me.

Edit: Hm not sure if this is normal but there seems to be a larger audio latency (> 200-300 ms) which wasn't as bad with VPN. If I go to a friends house instead of playing around at work I'll try hard wiring my shield to ethernet to see if that improves anything.
[Shield General] cgutman:
Glad to hear that it's smoother than VPN for you.

The Shield Relay is just the same Shield streaming traffic just sent over the Internet rather than your home network. This comes with benefits (speed) and drawbacks (lower reliability). Both of the oddities that you mention are probably related to packet loss, latency spikes, and routing changes that are more prevalent on the Internet than the average home network.

I suspect that the reason the stream drops during big lag spikes is because the lag spikes are due to packet loss or high latency. If the Shield's pings to the streaming PC get lost or arrive very late, the PC will timeout the stream, stop sending video, and the stream will drop.

The audio latency is probably due to variances in the latency and routing of the Internet. It's possible that the video packets and the audio packets take different paths through the Internet, so they can reach the Shield at different times. Normally the latency is close on a home network because there's only one route from your computer to your Shield, but the Internet can have tens or hundreds of routes to get your packets from point A to point B (sometimes even the route from A -> B is different than B -> A).

Nvidia could timestamp the audio and video packets so they can be played back at the same time, but that would force the Shield to delay displaying the video while it waits for the audio packets to come (and vice versa). Since this is a gaming feature, they probably don't want to introduce more latency.
[Shield General] -yz-:
ok how to know if everything if ok ?

ok how to know if everything if ok ? ?

i done everything like it write over here and i don't get any error just "stop" after i click run in the shield.

so everything working right?
[Shield General] cgutman:
Do you see both lines like "Shield is now communicating with us on port XXXXX" and "Relaying MDNS traffic to XXX.XXX.XXX.XXX" on the Shield Proxy running on Windows?
[Shield General] -yz-:
dmm...no i don't see it ...this is what i get when i run the

ShieldProxy.exe

all i get is "shield streaming proxy for windows v0.2"

joined MDNS multicast group with interface 192.168.1.13 (my pc)

listening on Microsoft for shield traffic

relay is up and running..."

what i am doing wrong .. i open all the ports i have RT-AC66U so..
[Shield General] cgutman:
Does your PC show up as available in the TegraZone app with Shield Relay running on Windows and Android? The start button on the Android relay doesn't do anything other than just start the relay service in the background. You still need to use the TegraZone app to access streaming. If you see an error message saying "We haven't received any DNS responses. Is the Windows Shield Proxy running on your PC?" then check that ShieldProxy.exe is allowed through Windows Firewall on public and private networks.
[Shield General] -yz-:
ok thank you for try to help me .

yes my pc show up as avaliable in TegraZone app with Shield Relay running on Windows and Android yes i know that i still need the nvidia shield app for stream i just try to see in the ShieldProxy pc app or in the Shield Relay any sign of connection i in my local home network right now so i can check if if work or not but i just want to see if everything working.

but i see in the cmd window of the ShieldProxy this "Relaying mdns traffic to ....and its my shield ip address ! so its a good sign i think.
[Shield General] cgutman:
The relay is hard to test while on the same network. Depending on your router configuration, it may only work correctly when the wrong IP address is specified in the Android app. Make sure that the IP address you've put in is an external IP address (not 192.168.x.x, 172.16.x.x, 10.x.x.x). If you specify an internal IP address, it will work when on the same network but not from another network, which defeats the whole point of the relay.

The only way to really test is to try it externally.
[Shield General] -yz-:
i don't set my internal IP address ...
[Shield General] cgutman:
In that case, it should work fine remotely.
[Shield General] -yz-:
ok

i will try if it work and update thanks ! for the help
[Shield General] Endorn:
not working

Mine's not working right, any chance of some help? I probably just missed something stupid.

What happens for me is:

I *believe* I'm connecting OK. In the windows program it says "relaying MDNS traffic to <ip address>"

when I go to tegra zone I can find my PC and select it, and launch a game.

but when I launch the game, I get a black screen. It sits there for a little while, then I get a "cannot stream due to network interference" error.

Any ideas?
[Shield General] HobsonA:
What connection is your streaming computer on and your receiving location? I've found the shield proxy is more sensitive to dropping connections on slower connections and high latency connections than VPN. However when conditions are right shield proxy is like a hundred times better in my opinion (I actually feel like I'm playing local when im connected on a decent connection remotely)
[Shield General] Endorn:
I don't know about the latency, but I have 105mbps down and 30mbps up so I doubt bandwidth is an issue.
[Shield General] HobsonA:
How about the location where you are trying to stream to? I'm assuming you router is also setup to port forward correctly.

Just for a basic comparison of what I run on that seems to run decently and maybe answer some of those can I run this questions.

My home computer is hardwired to a E2000 linksys router (Network: 30 Down, 5 up) Needless to say I'm very envious of your connection

I stream from my girlfriends house with some random disconnects if wifi signal gets poor. She has some run of the mill provided by ISP 2.4 ghz wireless N router connected to a network (10 Down, 1 up)

Pinging from her house to mine shows me a latency average of about 35-40 ms.

Mostly the experience is enjoyable over these conditions with some lag spikes and stuttering in video which id imagine would be fixed with a better router on her end.

Unfortunately get like two people watching netflix at her house and the ping becomes 100+ and the connection will drop almost all the time over streaming :( Frequent lag spikes will cause disconnect as soon as you open a game which would suddenly demand higher bandwidth.

Edit: I guess the tl;dr version is open command prompt at your remote location (I'm sure you could maybe do this on terminal app on an android device like shield but I never tried) and ping yourself continuously and see what kind of time you get. I know at work I get great 20-30 ms ping but every now and then I'll get a few seconds of 200+ms pings or request timing out and that shows when shield gaming usually leading to a disconnect with network interference or huge lag spikes

In Windows:

Ping -t <Address or hostname>

Not sure about in other operating systems
[Shield General] cgutman:
Make sure that you've properly forwarded all of the required ports to your machine. You've definitely got UDP 5354 coming through, but somehow the others aren't getting through. Make sure you've specified the right protocol for each port in your port forwarding settings (UDP vs TCP). It's also possible that nvstreamsvc.exe isn't allowed through Windows Firewall so that might be worth checking.
[Shield General] cgutman:
Shield Proxy for Windows v0.3 Released

I've put another Windows alpha up that forwards ports that the initial version didn't (47999, 48000). Hopefully this update addresses some of the connectivity issues. Please report if this update changes anything (positive or negative).

https://github.com/cgutman/ShieldProxyWindows/releases

v0.2 is still the latest for Android.
[Shield General] ben09in:
How to Shield streaming without a VPN

Over the past couple of weeks since I got a GTX 760 for my main rig, I've been playing with getting Shield streaming to work through a NAT. With a combination of an Android app and Windows app, I've been able to get the Shield to stream through a NAT device.This is alpha software, so it may not work for you. I'll be continuing development on it to make it more robust based on bug reports filed here and on the GitHub projects.
[Shield General] Endorn:
Just FYI I was able to fix my issue. I had lavasoft ad aware installed and even though I didn't think it had any kind of firewall on it, uninstalling it fixed everything.

This setup works amazing! (I was playing space marine on my lunch break today at work using it) It's awesome, thank you SO much for making this!!!

Anyone else feel like this is the future of all gaming?
[Shield General] clayton006:
After following all of the steps and forwarding all of the ports (as well as setting the computer as the DMZ) I get the following messages trying to run shieldproxy:

Joined MDNS multicast group with interface 10.0.0.1

Listening on <network adapter / driver name> (10.0.0.1) for Shield Traffic

Failed to bind UDP forwarding socket (10049)

Failed to register UDP relay

Failed to initialize pcap infrastructure

I have removed norton 360 from my computer, made sure that windows firewall is off. I've removed and reinstalled winpcap and rebooted a lot of times. Any other ideas?
[Shield General] clayton006:
Maybe there could be a way to log information about the proxy running. I've looked at a lot of directories but can't find any logging info for winpcap or the shieldproxy.