Closed kfatehi closed 12 years ago
With the last commit (re-fix #18 properly), we no longer get a crash -- now we just get the "fps is still 0" problem... trying to discover the cause
SavedCode.h/m... writing constants like RAMYDIDNTLIKETHIS to save code YOU liked... commenting huge chunks of bullcrap... olawd I remember this project.
Managed a preliminary reorganization of the project tree... noticing that ORGANIZE is a conciliating word for this codebase. Current tree: http://cl.ly/image/2D1g231n0D05 I'm beginning to appreciate the Xcode grouping system.
I've also organized the actual filesystem from that old mess... I should have done this sooner.
➜ Scribbeo git:(42_simulator_support) ✗ ls -l
total 24
drwxr-xr-x 8 keyvan staff 272 Aug 25 09:35 Frank
-rw-r--r-- 1 keyvan staff 2857 Aug 25 09:35 Scribbeo-Info.plist
-rw-r--r-- 1 keyvan staff 673 Aug 25 09:35 Scribbeo.entitlements
drwxr-xr-x@ 5 keyvan staff 170 Aug 25 11:26 Scribbeo.xcodeproj
-rw-r--r-- 1 keyvan staff 187 Aug 24 10:04 Scribbeo_Prefix.pch
drwxr-xr-x 4 keyvan staff 136 Aug 25 09:35 Settings.bundle
drwxr-xr-x 3 keyvan staff 102 Aug 25 09:35 fonts
drwxr-xr-x 59 keyvan staff 2006 Aug 25 09:35 graphics
drwxr-xr-x 3 keyvan staff 102 Aug 25 09:35 lib
drwxr-xr-x 54 keyvan staff 1836 Aug 25 10:54 src
drwxr-xr-x 8 keyvan staff 272 Aug 25 09:35 xibs
Figuring this thing out is a matter of examining the state of AVAsset (or AVURLAsset) as it gets loaded and the FPS is read. (The FPS won't get read if the tracks don't exist, this symptom was exposed through the timecode functions, the underlying issue is still there and would have left one scratching his head anyway... What is different?)
The root of the discrepancy is the absence of tracks on the AVURLAsset when we are in the simulator, but they exist when we are on device. Why?
Finding this out will be a lot of edit-recompile-repeat pattern, so I needed a shunt to get us directly to a video...
// OK we are here now, where we get MediaAsset URL's apparently,
// this is a nice point entry point -- ahh yeah filesFromJSONFileListing...
[[kAppDel viewController] loadMovie:@"https://app.scribbeo.com:44301/asset/TestFiles/chapter_markers.mov"];
// SHUNT
// Yessss shunt worked [On device]! we have an entry point of a ready player in the internets.
// The problem is, again, that we won't get here in the iOS sim...
// Clearly fails on the simulator because we havent fixed the AVAsset problem.
I've put this shunt in DetailViewController.m#filesFromJSONFileListing: to make us load a video from the server on startup. That method name confused me at first, but I understand it is called as soon as we "load into the app having logged in and authenticated and finally are ready for user input" ... the usual app startup locations were bad spots for this shunt -- so our "App starting point" may have been discovered here -- more on this later.
Oh and this:
This used to not happen -- perhaps git bisect is a good way to figure this out if not through the debugger directly or sheer analysis.
Bullshit, it always did this. I checked.
[theAsset loadValuesAsynchronouslyForKeys:[NSArray arrayWithObject:tracksKey] completionHandler:
^{
NSError *error = nil;
AVKeyValueStatus status = [theAsset statusOfValueForKey:tracksKey error:&error];
if (status != AVKeyValueStatusLoaded)
/* Found another symptom here.
Consider what `status` could possibly be:
enum {
(0) AVKeyValueStatusUnknown,
(1) AVKeyValueStatusLoading,
(2) AVKeyValueStatusLoaded,
(3) AVKeyValueStatusFailed,
(4) AVKeyValueStatusCancelled
};
On the device, status returns 2, AVKeyValueStatusLoaded
On the sim, status returns 3, AVKeyValueStatusFailed
Why?
*/
self.playerItem = [AVPlayerItem playerItemWithURL: movieURL];
else
self.playerItem = [AVPlayerItem playerItemWithAsset: theAsset];
if (self.player) {
[self.player pause];
//[self.player release];
}
Printing description of error: Error Domain=NSURLErrorDomain Code=-1013 "The operation couldn’t be completed. (NSURLErrorDomain error -1013.)" UserInfo=0x95a6cf0 {NSErrorFailingURLStringKey=https://app.scribbeo.com:44301/asset/TestFiles/chapter_markers.mov, NSErrorFailingURLKey=https://app.scribbeo.com:44301/asset/TestFiles/chapter_markers.mov, NSUnderlyingError=0x91c0e30 "The operation couldn’t be completed. (OSStatus error -12937.)", NSURL=https://app.scribbeo.com:44301/asset/TestFiles/chapter_markers.mov}
hmm... maybe the cookie isn't getting sent correctly when AV makes that request and so we get an error... let's try an arbitrary URL (e.g. google.com) that will definitely fail on both environments and see if we get a similar error
error code reference: https://developer.apple.com/library/mac/#documentation/cocoa/reference/foundation/Miscellaneous/Foundation_Constants/Reference/reference.html
code -1100: NSURLErrorFileDoesNotExist Returned when a file does not exist. Declared in NSURLError.h.
I just got Scribbeo to play video in the simulator. I had it play from a bare ruby on rails app server not using SSL or auth.
self.movieURL = [NSURL URLWithString:@"http://192.168.1.6:3000/videos/chapter_markers.mov"];
self.theAsset = [AVURLAsset URLAssetWithURL: movieURL options: optionsDict];
I'll need to inspect the server logs a bit more in depth to know more details but I finally figured out the solution to this problem.
Frank tests are going to automate Scribbeo's interaction with a CAPS that is using SSL, but in regular development it needs to be working with HTTP before we make it HTTPS.
Video streaming in the simulator will only be necessary when running automated tests, if necessary we may be able to have the server/app in a hybrid state where everything (auth, note data, etc) is done by SSL except video streaming, so that timecode and other things can be tested properly through automated tests.
Anyway, now that I know it works with HTTP I am happy to continue on with the reorganization and can focus on the server protocols...
This sucks as it prevents us from efficiently running our Frank tests (because we'd always need a hardware device). Needs immediate fixing before we can do proper BDD towards our goal of a unified Scribbeo app.
Replicating the bug: Run Scribbeo on the simulator and select a video, the video will not load, instead the application hangs and you are thrown into the debugger.
This used to not happen -- perhaps git bisect is a good way to figure this out if not through the debugger directly or sheer analysis.
Screenshot: http://cl.ly/image/0c1h1B222r2V