Yes, you're correct; If you have your filter set to "Include Packets in Area Visible map boundaries", it will send a "a/latN/lonW/latS/lonE" filter to the server that will update when you pan/zoom the map. You should be able to see the updated filter go out if you are watching the log.
I have experienced some instances in the past where the remote side of the socket (the APRS-IS server) hangs up and QTH.app doesn't seem to get notified. I have attempted to fix this by enabling keepalives and setting the timeout appropriately, but I think this tends to happen primarily when the system goes to sleep and then wakes up. It never seems to happen while I'm actively using the system, only when I leave it running overnight and wake it up in the morning. This doesn't seem to be the same as your situation, though, since it sounds like you were still receiving other packets.
At the very least, if QTH.app receives a packet from APRS-IS that it cannot parse, it will definitely report that in the log; it should never fail silently in that regard.
I am currently doing some work on the tracking part of QTH, so if it was a bug in the tracking support, hopefully it will be improved in the next update.
However, if the APRS-IS server never sends the packets to you, I'm really sure how to fix that; it seems like it would be an upstream issue.
If you have a station that you are watching and you think it might go out of the range, Lynn's advice is great; I would recommend a "Budlist filter", where the equivalent in QTH.app is a filter of "[include] [callsigns] [in] CALL1,CALL2,etc" I personally have everyone in the beta in a custom buddy list so I can see the packets regardless of range.
I like Lynn's idea of an automatic buddy list filter. The groundwork is already there in QTH. You can already mark stations as favorites; it would be trivial to collect those into a filter list.
- Wes, W8WJB