Notices

IMO, choice is King! So, by all means let's have unthrottled as an option but the current refresh rate option as well (incl. your loops etc).

I really like this. And at a refresh of every 10 secs it is very economical on battery too.

One thing: I think under some or other yet to be determined circumstance it might cause a prompt for connection. Not sure it is fettucine however. Certainly difficult to reproduce and it may just as well be Yappari (in my case the most likely alternative).

Tested. Exited yappari, disconnected wifi and allowed screen to blank. Upon touching screen, connection dialogue appeared. I think it is fettucine.

App is well behaved if screen stays lit and the connection is unavailable. And it remains well behaved even if the screen blanks after one has rejected the connection dialogue. That is, the dialogue pops-up only at the return from the first screen blank after the connection is closed.

Related - it might be a good idea to overlay some symbol or label when the displayed image is "old/stale" due to the absence of an internet connection, or being paused.

Addition to the above:

the widget misbehaves more severely at device start-up if no connection is available - persistent connection dialogues whilst widget displays message "loading camera" or some such.

Also, I had a non-default width and height entered and that was lost across the reboot.

Hi folks! Version 0.9.5 of Fettuccine is now working its way into the Extras-Devel repository. This iteration doesn't yet fix all the problems in 0.9.4, but I think it's enough of an improvement to go ahead and push it up.

First up, display of MJpeg streams at full speed is now supported (and some webcams stream pretty dang fast). The previous two options are still supported as well; but in order to accomplish this, I've once again changed the XML syntax. The three options are now defined as "MJpeg_Full" for full speed, "MJpeg_Sampled" to pull an individual frame out at a specified refresh rate, and "MJpeg_Looped" to pull a sequence of frames out and loop through them. An example of these three options:

The "refreshRate" is omitted for "MJpeg_Full" (as, obviously, the display is refreshed as fast as the data comes in). For the other two webcam types, the various options are still the same as in my previous post.

Unfortunately, this syntax isn't backwards-compatible with last week's XML, so you'll need to rewrite any scripts using the old "MJpeg" webcam type to get them to work.

I have also implemented a pause & resume function; if you bring up the on-screen controls, you'll now see a pause icon. You should be able to hit that to pause the data retrieval, and then hit it again to resume retrieving data from the webcam. I'm fairly certain that it works correctly in all situations, but please tell me if you have any problems with it. I'll attach some screenshots at the end of this post.

I've tried to make Fettuccine a little better at handling network outages, but this is still going to take more work...

And yeah, the Fettuccine widget is not saving state information across a reboot (or across anything else). My hangup with that right now is that I don't know how to uniquely identify instances of the widget; if you have two or three of them running on your desktop, how do you know which one should have which size (or display which webcam)? I could just give them index numbers in the order they were created, but will they be created in the same order after a reboot? I could identify them by their location on the desktop, but I'm not sure where that data exists (or if it is visible to the app), and that would also require keeping track of when the user moves them... I guess I need to do more research.

Hi,

thanks for the improvements. The widget indeed handles connection absence better - it shows "paused" when screen returns from sleep and a touch re-enables.

One weirdness - whilst the widget works for my cam, the application does not. "Loading webcam" shows but the image never displays.

Further, even when connected by wifi, the application shows "fettucine failed to access internet".

As for the widget display size, why not store that in the xml? Is there a point to having multiple widgets, each showing a different webcam from the same xml BUT with different display sizes?

Hmm. That really is weird; the widget and the app are for the most part running the exact same code; only the top-level UI elements are different...

Well, that might explain why the app shows "Loading webcam" (which is, in fact, the default label shown when there is no data; I need to fix that!). But then, I don't know why it failed to access the net in the first place. (Is this just for the one webcam, or for any webcam? If you hit the play icon, does the same error message come up?)

Ah, well, I can't even get that far -- say I have two widgets. Widget #1 is constructed, and says "Hey, I'm a widget! What sizes and webcam should I use? I don't know which widget I am, so I'll take the data for widget #1." Then, widget #2 is constructed, and also says "Hey, I'm a widget! What sizes and webcam should I use? I don't know which widget I am, so I'll take the data for widget #1."

Oh well. For now, I've decided to just bypass this mess and not allow multiple widgets. I've got a version of Fettuccine which properly maintains widget state information now; I'll try to get it pushed up soon.

Ok, Fettuccine 0.9.6 is on its way up to extras-devel. The main change in this version is that widget state information is now properly maintained! Sadly, this was achieved by disallowing multiple widgets. This limitation was set in the .desktop file, so it won't be updated until the Hildon desktop is restarted (or the phone is rebooted).

I've also fixed a little bug where pause/resume state was not being set properly.

Handaxe, I'm still not sure what the network problem might be; I'll keep working on it...

Hi, thanks. For now, let me say that the app DOES work. It did not for me earlier but that may have been a slower wifi link although I did watch the app for quite a while. So sorry for that..

I now have figured out:

the error in "accessing the internet" message in the app still displays even when the connection is up;

the app always starts paused (that might be ok);

the app will not load the image until one re-selects the camera from the drop-down menu (this is true from start-up AND in using the pause/resume function and on return from sleep ie. when pause is showing).

The widget will also produce the error in "accessing the internet" message after returning from a disconnection of the wifi and manual screen blank. The image will then not load until the webcam is re-selected as is in the case of the app.

Ah, well, I'm now having Fettuccine go into paused mode whenever there's any kind of network problem...

Hmm. The error message "Fettuccine failed to access internet" is displayed whenever the QNetworkAccessManager object sends a signal that the network is not available. This message should never occur when the network is actually up; although, I could imagine that it may take a few seconds before Qt recognizes that network availability has changed.

Now, this is confusing. I think this would have to mean that something has gotten really messed up (either the webcam URL or something to do with the Qt networking), but that just reinitializing the URL fixes everything...

I have to admit, I've never seen this exact behavior before. If I may, can I ask that you test for this behavior using a different webcam (such as, say, the Old Faithful webcam)? Maybe there's something unique about your webcam. Thanks!