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.
hth
Hi,
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 ?
Calvin.
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.
Support Migration
--- Import ---
Author: Calvin MELEN
Created At: 2015-11-02T12:37:32+08:00
Updated At: 2015-11-02T12:37:32+08:00
Views: 98
Votes: 0
--- Import ---