Login  Sign up

JMR - Enhancement Suggestions

Hi all at Jaksta, Just a quick email about JMR 6.0..0.90 Firstly it is FANTASTIC to see an Australian product making a mark on the world stage. I've been a proud owner for a couple of months, an on the whole it works REALLY well. A few suggestions about feature enhancement/changes that i think could make the product even better: 1. Add the option so that if you attempt to deselect "auto" on the main screen whilst 1 or more "recordings" are in progress you receive a warning that all "recordings" in progress will stop. I found out about this little trap the hard way - and now have about 5 once off recordings with "holes" in them :-( 2. Some cam sites are NOTORIOUSLY poor quality and have streams that suddenly stop or "orphan" without warning and for no good reason. Could we add an option in Jaksta to "watchdog" downloads and recordings, such that if a recording or download shows no progress (ie: the time is not advancing) for longer than say 30 (or make it adjustable), it attempts to restart, or pops a dialogue warning that a file seems to be "stuck" 3. Could we add a option to the file naming rules that allows a name to have a date/time tag appended to the end - built from the system date and time at the moment the recording starts. Format of the tag preferable to ensure easy sorting later would be (FileName built from other rules)-YYYY-MM-DD_HH-MM. This would make files unique and we wouldn't need the arbitrary appended 1, 2 etc... All the best, Calvin.

Glad to hear your enjoying the product.

Ive added 1 to the suggestions database.

2 is complicated. Most urls are only valid for a short period. If the download becomes stuck as the cam has gone away then a refresh of the hosting page is required to pick up the new url the cam is broadcasting on.  That page is normally not available to JMR as the stream url alot of the time has no reference to the hosting page..  What site are you experiencing the cams dropping on?

3. The ID3 naming rules already support adding dates/times to the file name.  If the raw steam is flv you need to convert to a format that supports ID3 tags such as mp4.  See the naming rules tab in the settings.  The scheduler also supports this.  See the override tags tab.



Thanks for the quick reply.

Regarding Item #2 - several sites have issues in this regard. If I could highlight the two WORST offenders:

1 - Cam4 (Please DON'T ask me about what I think of THEIR coding efforts - the description I am likely to give would UNDOUBTEDLY be defamatory !)

Cam4 OFTEN "drops" a stream for no reason - THIS IS THEIR FAULT, not JMR's I realise. I normally capture from Cam4 in download mode - when you get a "download stop" situation in JMR if you are watching the live web page stream with flash player the video often "glitches" or drops out for anything up to 30 secs. They also have this appallingly ROUGH sudden camera resolution change mechanism which makes the stream glitch badly. This can often make JMR lose it's grip on the situation and the download will stop.

The "restart" option in the JMR context menu for the downloaded file OFTEN restores the download - starting a new file of course.

On other occasions Cam4 have obviously dropped at the sender end, the URL DOES then change and you have to go through setting the download back up again - I understand JMR is unable to recover in these circumstances and requires manual intervention. When a "DROP" occurs (in either scenario) JMR ordinarily signals as "download complete" so at least you get warning that something has happened. - It would be nice if JMR had an option to at least TRY to get the stream back, then signal stopped if the attempt fails. I would also suggest that the be a timer prior to the restart attempts - Cam4 seems to take anything up to 30 seconds to sort itself out when it all goes wrong as described above.

2 - Chaturbate - The issue here happens a lot less often and is VERY difficult to catch. If you look at JMR when it happens it will list the item as "recording", but the duration timer has STOPPED advancing. It will sit in this "frozen" state indefinitely.

Meanwhile if you go over and check the Flash web page the stream is coming from, it is still running fine. I haven't YET been able to catch exactly WHAT (if anything) happens on the camera web page at the moment the JMR recording "freezes". Again most likely a "glitch" in the video stream of some form or another.

As I asked you about originally - in this circumstance a "watchdog" keeping an eye on the duration timer and popping a warning telling you that the stream recording has "frozen" would be VERY helpful.

As to item #3, I ordinarily don't "convert" the incoming videos I record, they stay in native format, so in the majority of cases *.flv.

Is their a method to implement the naming rules you spoke of in the ID3 rules area where conversion of files is NOT required ?


Ive added both to be looked at to see if there is anything practical that can be done to help recover in the situation where the stream drops.  

ID3 naming rules are the only method for adding timestamps at the current time for video.  Ive added a suggestion to the database to allow time stamping of the initial file name.

Thanks ! I realise that JMR is NOT at fault -and I appreciate anything that can be done to make things a bit easier when it all goes wrong.

As usual other people seem to have to spend an AWFUL LOT of time and effort coding around the DREADFUL efforts that pass as "finished" code on the cam sites :-(


Login or Signup to post a comment