I know... point is, if i explicitly tell iCamSource a folder I want the motion events to be stored in... it should use THAT folder. Not a subfolder of that folder.
I have 3 iCamSources... and I've created a human readable, friendly folder for each... "01 - Basement", "02 - Den", "03 - Backyard", for instance... not so appealing to have "01 - Basement" \ eu38eueoifhidsr893udioeioewuiore (example) \ [meaningful events here]
I think there could be an advantage to adding a scrubber to the UI when viewing a recorded motion event. Currently you can only play, or move forward or back a shot. There is no way to quickly jump ahead (or back) when reviewing an event - which is helpful for a longer recording.
Another opportunity for improvement... In addition to a standard iCam user, with the capabilities that currently exist, I think there may be value in having a 'real only' account, which will have no abilities other than viewing the live feed. They would not have the ability to enable/disable motion recording, motion detection sensitivity, alert notification, deleting motion events, etc. In fact, they may not even have access to view motion events - to be decided, I suppose.
My wife and I both access our webcam feed, to keep an eye on the house, and the kids while sleeping - etc. (either when we're home, or out with the kids in babysitter's care). My wife has no desire or intent to change settings, but given that all the adjustment options are front and center when using the app, it makes it far too [accidentally] easy.
I think a little UI improvement may be in order for the iOS app. When in the zoomed view, looking at a single camera, the "Record Motion Events" toggler, found in the top left corner of the screen is the spot that the non-existant "Back" buttom should be.
This causes two issues:
1. Inadvertantly, it makes disabling motion recordings too likely and accidentally switched off. 2. Breaks the user experience model, causing a slight bit of confusion as to how to exit the 'zoomed' view.
Seems like an easy fix. Maybe move it to the bottom, or two a 'flipped' settings page, along with the other 'sensitivity' and 'alert' settings, which an end user may not intentionally want to alter easily.
On my instance of iCamSource, I currently have 3 network cameras being monitored, with motion detection enabled and set to record. I've also got dropbox running, and have created a folder within my dropbox called iCam. Within the iCam folder, I've created 3 folders, with friendly names, to distinguish the 3 different cameras.... and have set each iCam Source Cam to point to a specific one of these folders.
I didn't learn about the 'hash' subfolder until after... and am a little disappointed that it exists, without an override option (either to disable it, or to specify what the subfolder should be).
Looks like 2 of the 3 trendnet's have a sporadic issue with the JPEG feed. Anywhere from immediately after a camera reboot, to a day later, the jpeg feed stops working. This happens even when I access the URL directly from a web browser. I've reported the issue to TrendNet, not sure what will come of that.
I switched the IP-312 and IP-312W back to the MJPEG feed, but instead of using http://[IP]/cgi/mjpg/mjpg.cgi, I've been using http://[IP]/cgi/mjpg.cgi, which seems to have been working well. Just to test, I switched back to the original URL http://[IP]/cgi/mjpg/mjpg.cgi, and the original issue occured again.
I noticed, however that the 'new' MJPEG url doesn't have audio. Can you add this to your list, and create a new build for me to test with?
Over 24 hours later, and all the cameras are still in sync. That's even with enduring a partial home network outage (due to a tripped breaker), etc... all resumed as normal, without any intervention.
Looks like this may be a plausible solution!
Can we work on adding the audio back now?? Maybe a pre-release build to test?
No, unfortunately the issue presents itself across all/any of the cameras. In fact, sometimes it's most often with the wired one (or perhaps it just feels that way, because that's the one by our daughters crib... which we tend to keep an eye on the most.)
I'll change them all to a JPEG url right now, and keep our eye on it.
The webpage is always accurate/timely, regardless of how iCamSource is performing.
When iCamSource is behind, yes - it still streams, but is delayed. If I am on the host computer, interacting with iCamSource, switching between the cameras, all the streams are moving, however the affected streams are lagging in time. When I interact with iCam on my iPhone, iPad - the affected streams take longer to appear, I believe relative to the time the stream is delayed, but then 'move', again still lagging. i.e. if Camera 1 and 3 are ok, but Camera 2 appears 30 seconds behind... through the iOS interface, Camera 1 and 3 appear immediately, while Camera 2 takes that same amount of time (say 30 seconds), to appear. I believe iCamWeb behaves similarly.
i've added all 3 back with the URLs as specified originally, and switched each toggle to JPEG. it wasn't long before the issue occurred again... and again, the camera that had lag also presented the 404 error.
I dropped it down to a single IP Cam, leaving it as MJPEG. Within a few hours, I noticed the clock was about 10 seconds behind. iCamSource presented the 404 error within.
I've not tried the JPEG setting yet, because I believe doing that would then not allow me to have audio.
Please let me know next steps to help resolve this. Perhaps there is some debug logs I could provide?
Show Posts
