View Full Version : [MB Premium Twin HD] Power Timer looping (and eventually crashing enigma2).
I switched the TV today and flipped it over to the MBT input.
There was a po-up present, saying
A finished powertimer wants to set your Miraclebox Premium Twin to standby. Do that now?
and a timer was counting down (with "yes" selected). Out of interest (v.i.) I left it. When the counter reached 0 it just went back to 180 and started again. And when that one reached 0 it went back to 180 again...
So at that point I selected "no" and pressed OK. The box then went straight into standby.
So I presume that what is actually happening is that that when the timer gets to 0 instead of switching the box to standby it is starting another timer: only when I cancelled a timer did a previous one switch it to standby.
The reason that I left it is that yesterday I noticed that the front panel was displaying "A finished..." and I found enigma2 unresponsive with the top left logo spinning. (I was able to login to the box and reboot it.).
Looking at the debug log then wasn't all that helpful as it had been overwritten with a loop of:
< 17285.666273> Backtrace:
< 17285.666706> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x45E910]
< 17285.666945> /usr/lib/libpython2.7.so.1.0(PyObject_Call) [0x7753BEDA]
< 17285.667085> -------FATAL SIGNAL
< 17285.667191> PC: 7753bed8
< 17285.667253> 00000000 00000001 7767d210 776aa644
< 17285.667323> 00000000 7294cb70 00000000 729e7e2c
< 17285.667389> 80808080 0000004e 00000000 00687461
< 17285.667457> 2e303338 32303234 203e3834 2d2d2d2d
< 17285.667523> 7294cb70 7754f628 72d552d8 7294cb70
< 17285.667587> 740653f4 740652a8 77d09000 005c0000
< 17285.667662> 00000018 7753be9c 00000000 00000000
< 17285.667728> 776ac150 74065040 74065a20 775e68c8so I was wondering whether the timer was looping until it ran out of stack, resulting in a signal that itself produced a loop...and it looks like I could have been right.
Here's the debug log leading up to the shut-down mentioned above: 45549
It shows two "Timeout!" messages (from timeoutCallback() in MessageBox.py), then I press Down and OK (to select "No") followed by the immediate switch into standby.
PS: my daughter has also (recently) reported having to back out from many MessageBox timer prompts...
@birdman - I found so many issues with the MB Twin as regards booting from deep standby to record on the ViX image that I tried the OpenATV image for several weeks. Rock solid as regards booting into standby mode for recording and dependable for shutting down afterwards. There are workarounds in the ATV code which are not present in ViX code to handle the quirky behaviour of the MB drivers to allow detection of timer boots and also to handle the front panel icon etc. It's worth a try if you find ViX less than ideal on the Miraclebox.
I have no problems at all with it booting up for recordings.
As for the Front Panel; from what I can see one issue is more in the OpenVix code thna any hardware driver - as I have code that drives the recording indicator fine - and it's driven by the code that starts and stops recordings (which is the obvious place to put it, but OpenVix has none there).
The only issue is around the Power Timers (which I wouldn't expect to be hardware-dependent), which seem to work only randomly and, in the case reported here, catastrophically.
I have no problems at all with it booting up for recordings.
As for the Front Panel; from what I can see one issue is more in the OpenVix code thna any hardware driver - as I have code that drives the recording indicator fine - and it's driven by the code that starts and stops recordings (which is the obvious place to put it, but OpenVix has none there).
The only issue is around the Power Timers (which I wouldn't expect to be hardware-dependent), which seem to work only randomly and, in the case reported here, catastrophically.
Code or patch so? rather than long winded nonsense?
Code or patch so? rather than long winded nonsense?I was told that the problem (for the FP) was in the MBTwin drivers and that the OpenVix code was fine and in no need of any patching.
As for the Power Timers - I'll be adding some debug statements to see whether I can determine the problem.
@birdman - I recall that you were looking at the recording icon code some time back. I had issues with the icon handling in ViX also and Andy indicated that it was issues with the driver implementation in MB. A year on and still no improvement in the MB drivers. OpenATV has a raft of code hacks and a load of settings tweaks to handle the icons in the MB and also additional code to handle timer recordings in standby after booting from deep.
@judge - I don't think any of these hacks will make their way into ViX due to the priorities of keeping the code clean, so it's really a matter of choice for the end-user to decide if they want the extra features to go with a different image and potentially have stability or support issues.
A year on and still no improvement in the MB drivers. Except I don't see a problem with them. If you tell them what to display they do so (and it should be up to enigma2 to know how many recordings are in progress).. The only issue appears to be that you have to tell it to display nothing when it first boots (which seems reasonable to me).
Anyway - nothing to do with the problem in this thread.
You quoted me a bit out of context, there birdman ;) It's a ViX dev's view that the drivers are not up to the job. Other images have "worked around" the apparent issues and the end-user experience is fine as regards the FP display icons, so there are alternatives...
It's a ViX dev's view that the drivers are not up to the job.OK. But when i try to find out what drivers should be doing I'm told that vendors should know - a bit odd (to me) since if no-one can tell me, how can anyone tell the vendors so that they can know?
I can't even find the code that sets the "currently recording" status on the front-panel, even though it was doing it (wrongly) in the standard OpenVix image.
I could make my small change check that it's running on a MBTwin (with a check that could be extended to any other box with a similar FP issue) and submit that. The MBTwin actually has 4 different recording icons, so the code is set to display a different one for the number of recording mod 4 (but that 4 could easily be made boxtype-specific).
Now, back to Power Timers.
I decided to have a look at was was actually set on my box today. It should have been one for AutoStandby and another for AutoDeepStandby, only active when in Standby.
But what was actually there was 3 of each(?!?).
<timer timertype="autostandby" begin="1446725011" end="1446725011" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446725011" end="1446725011" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446725004" end="1446725004" repeated="0" afterevent="nothing" disabled="1" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446805758" end="1446805759" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
That was after I'd tried to delete some of the autostandby onesi n the PowerTimer menu (which didn't seem to go away...).
So just to be sure I went to yesterday's backup, and that had a similar set:
<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autostandby" begin="1446630039" end="1446630039" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="autodeepstandby" begin="1446714278" end="1446714279" repeated="127" afterevent="nothing" disabled="0" autosleepinstandbyonly="yes" autosleepdelay="20" autosleeprepeat="repeated">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<timer timertype="wakeuptostandby" begin="1438074000" end="1438074000" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
(No idea where those wakeuptostandby ones came from - perhaps I was doing some experimenting in July...).
Odd that everything seems to be in triplicate.
Anyway, I've deleted them all and installed the two I expect to be there. And will see what happens...
I really think you're wasting your time digging into why the ViX code is not working properly with the MB Twin ;) There would seem to be little appetite to fix issues on the box while there is a perception that the drivers are not up to snuff. Try OpenATV and see how it works out. You might be surprised.
I really think you're wasting your time digging into why the ViX code is not working properly with the MB Twin ;)I know why it isn't working - which is why I've been able to (trivially) fix it (not on my own - someone else, adm?, did the first draft).
The issue is that the support team say that the drivers are broken, while at the same time being unable to give any indication at all as to what the drivers should be doing. Apparently vendors are just "supposed to know".
abu baniaz
06-11-15, 02:24
I wish the driver specifications were documented somewhere. Sadly this isn't the case. Maybe check on the PLi site?
Pretty sure the proof that it was a driver issue was posted recently. Hope this is it.
but looks like the driver file /proc/stb/fp/was_timer_wakeup is not being set to 1 at timer box wakeup
Someone tried to look for the modifications added into the openatv image to deal with the issue, but they couldn't be found. If someone can find them, please post them.
but looks like the driver file /proc/stb/fp/was_timer_wakeup is not being set to 1 at timer box wakeup That's an issue with "recording timers". "Should I go back to sleep after a recording?". On an MBTwin you don't know why it woke up - but I can live with that. (A possible workaround would be to assume that if no key has been pressed since boot-up when a recording finishes then it was woken up for a timer).
The issue I have is with the front-panel indicator that a recording is currently running. With the default image this behaves almost randomly on an MBTwin (and will always come on after a standby/wakeup state change). Given that the icon "moves" (it's a rotating disk) it's annoying to have it permanently on when it doesn't mean anything.
I've updated my code to work on any box with a working symbol_record (to store no. of current of recordings) and symbol_circle (active if non-zero - you configure the number of different states that the box has) in /proc/stb/lcd.
Once again, in case I wasn't clear in previous posts - the OpenATV image has settings for the FP that will manage the icon states. You can turn the icon off permanently, have it rotate while recording (and off when not recording) and some other tweaks. You can manage the wakeup from deep standby behaviour. The code checks (at boot time) to see if there is an upcoming timer event within the next 600 seconds and sets the /proc/stb/fp/was_timer_wakeup flag because the FP microcode/driver does not do it.
From debate in other threads I would think that these workarounds are unlikely to make their way into ViX code.
OK. An update...
PowerTimers
Having deleted the weird timers I had and setting up the two I wanted, all now seems to be OK.
I looked through the PowerTimer code and discovered that they aren't implemented the way I thought they were. I'd assumed that an 30min repeating Auto DeepStandby timer set to only run when the box was in Standby would cut-in 30 mins after the box went into Standby. In fact it runs every 30 mins and each time it runs it checks whether the box is in Standby at the time - so 30 mins is the longest time it would take to kick-in. (There is also a back-off time involved here, but that ends up at 30mins as well).
The Auto Standby timer is similar.
Both timers get restarted on any key press.
Whilst looking at the code I discovered that there was nothing in the Auto Standby code path to check whether a recording was being viewed before popping up the prompt to go to standby. This is annoying - so I've added (and tested) code to do the check, and will no longer get prompted during a viewing.
I'll post the code later.
OpenATV and recording icons
Well, at least it makes the attempt; but it still only uses one (of four) settings (oddly it uses the value "3", so it must know there are multiple ones). So I'll stick with what I have (it's not exactly difficult to do).
I'll post the code later.
OpenATV and recording in standby
This isn't too much of an issue.
Oddly - I had a recording this afternoon with OpenVix which was done with a wakeup to standby. No idea how it happened, but it's not the first time I've seen it.
Wait!! I had only shut the box down 10 mins earlier, so it would have woken up at the "expected" time - rather than the normal 30mins early that happens after several hours shutdown - so perhaps OpenVix has a similar kludge to OpenATV aready?
Here's a quick link to the code changes...
http://birdman.dynalias.org/OpenVix/
Well, someone was reading this and paying attention as the code to skip the Standby request when playing back a recording has gone into 3.2.024. And whomsoever did it also added the test to the Auto Deep Standby branch too (which I'd forgotten, as my AutoDS timers only activate when the box is in Standby).
Well, someone was reading this and paying attention as the code to skip the Standby request when playing back a recording has gone into 3.2.024. And whomsoever did it also added the test to the Auto Deep Standby branch too (which I'd forgotten, as my AutoDS timers only activate when the box is in Standby).
I didn't try 3.2.024, but I've just moved to 3.2.026 and this "feature" doesn't seem to be there anymore. :confused:
I didn't try 3.2.024, but I've just moved to 3.2.026 and this "feature" doesn't seem to be there anymore. :confused:Well, the code is still there.
Hmm....wait. When you say that the feature doesn't seem to be there any more, is that because you've been prompted while watching a recording?
The fix referred to Power Timers. So if you are being prompted, is it a result of a Recording Timer which is set to do something when finished? It looks like that may be covered (since the code is in a different file...).
Hmm....wait. When you say that the feature doesn't seem to be there any more, is that because you've been prompted while watching a recording?
The fix referred to Power Timers. So if you are being prompted, is it a result of a Recording Timer which is set to do something when finished? It looks like that may be covered (since the code is in a different file...).
Apologies - I'm getting the prompt (as always), when a recording timer ends while watching a recording.
Apologies - I'm getting the prompt (as always), when a recording timer ends while watching a recording.I'll have a look at that. May not be for a day or two, though.
I'll have a look at that. May not be for a day or two, though.It was quicker.
See the "No shutdown prompt while watching recording entry" at:
(http://birdman.lack.local/OpenVix/patches/FP-Icons)
http://birdman.dynalias.org/OpenVix/
It's just a matter of leaving the activate() function before testing whether to prompt (which is the final thing that function would do).
Thanks for sorting it out so quickly - it'll be tomorrow before I can try it out.
It was quicker.
Works a treat. Thanks again.
(FP checks ok as well.)
(FP checks ok as well.)So you have an MBTwin?
So you have an MBTwin?
No - I (knew) I should have made my last comment clearer, just to say that the FP patch doesn't cause problems if the box isn't a MBTwin.
I was undecided whether to leave the code in, but clearly the checks for box type work ok, something which is not always easy to test for.
... but clearly the checks for box type work ok, something which is not always easy to test for.
from boxbranding import getBoxType
...
mybox = getBoxType()
works fine.
What I'd really like to know is which other boxes have a /proc/stb/vfd/symbol_circle which changes an indicator on the front panel, and how many different states it has (i.e. if you echo 1 then 2 then 3... to it, how high can you go before it stops producing a different indicator).
I did have a look last night, and the ET10K hasn't.
from boxbranding import getBoxType
...
mybox = getBoxType()
works fine.
What I'd really like to know is which other boxes have a /proc/stb/vfd/symbol_circle which changes an indicator on the front panel, and how many different states it has (i.e. if you echo 1 then 2 then 3... to it, how high can you go before it stops producing a different indicator).
Hi
Gigablue Quad Plus box here and it doesn't have the folder /proc/stb/vfd/
Hi
Gigablue Quad Plus box here and it doesn't have the folder /proc/stb/vfd/Well, it turns out that neither does my MB Twin! I meant to check that path before posting the original, got distracted then posted what was there.
What I'm actually interested in is /proc/stb/lcd/symbol_circle and what happens when you echo 0, 1, 2, 3, .... to it should it be there.
Hi
Gigablue Quad Plus box here and it does have the folder /proc/stb/lcd/ but of the seven files there, none are Symbol_circle.
ET10K has
-r--r--r-- 1 root root 0 Dec 4 18:58 bpp
-r--r--r-- 1 root root 0 Dec 4 18:58 oled_brightness
-r--r--r-- 1 root root 0 Dec 4 18:58 xres
-r--r--r-- 1 root root 0 Dec 4 18:58 yres
abu baniaz
14-12-15, 16:22
@Birdman, can you try this file please and confirm if it fixes your premature deletion? It is slightly different to your file, but should serve the same purpose.
Thanks.
@Birdman, can you try this file please and confirm if it fixes your premature deletion? It is slightly different to your file, but should serve the same purpose.
Thanks.Yes, that fixes it.
It was quicker.
See the "No shutdown prompt while watching recording entry" at:
(http://birdman.lack.local/OpenVix/patches/FP-Icons)
http://birdman.dynalias.org/OpenVix/
It's just a matter of leaving the activate() function before testing whether to prompt (which is the final thing that function would do).
Would it be possible to check if the box is being used (watching a recording) remotely from another room? :)
Would it be possible to check if the box is being used (watching a recording) remotely from another room? :)Well - it wouldn't have been easy at the time, but a week or so later some entry points were added to enigma's C++ code to list remote streamers.
Not sure whether these are accessible via Python yet, though. If not someone will need to figure out how to make them so.
Not sure whether these are accessible via Python yet, though. If not someone will need to figure out how to make them so.
Components/Converter/ClientsStreaming.py was added on Dec 30, 2015. Looks like it should do the job.
I'll work up a patch shortly...
Components/Converter/ClientsStreaming.py was added on Dec 30, 2015. Looks like it should do the job.
I'll work up a patch shortly...OK - it does work.
Both PowerTimer.py and RecordTimer.py need it.
There are now patches in both the PruneTimerLogs and No shutdown prompt while watching recording entries at:
http://birdman.dynalias.org/OpenVix/(the *NoShutdown* patch in each).
The one for RecordTimer.py also includes the patch for checking whether a recording is being watched.
The PowerTimer patch delays the shutdown while the RecordTimer one discards it completely. This is because of how the do_backoff() function works (differently) in the two files.
Don't seem to be having any success.
RecordTimer.py is still working ok for watching recordings directly on the box, but streaming recordings still gets the shutdown dialogue.
Don't seem to be having any success.It worked when I tested it....(for a finished recording).
RecordTimer.py is still working ok for watching recordings directly on the box, but streaming recordings still gets the shutdown dialogue.Interesting wording.
Are you saying that a message pops up on the streaming recording display?
Or that the shutdown prompt shows up on the box even though you are streaming?
And is this after a recording stops, or for a scheduled Power Timer? If the latter, then you need the patched PowerTimer.py (whcih is in the PruneTimerLogs directory (as their is code for trimming auto-repeating log entries as well).
"The shutdown prompt shows up on the ET10K even though I'm streaming, after a recording stops."
I'm not using powertimers at all at the moment.
How am I streaming - kodi on a fire tv. No plugins on the ET10k. Samba, though, is enabled.
Just tried streaming with OpenWebif.
When the timer recording ended, the dialogue box popped up as before on the et10k, 3 minute countdown, and then started another 3 minute countdown before going to deep standby.
Just noticed something significant - the last 45 minutes of the 1hr programme were buffered up on the pc, so maybe there was no
streaming going on!
I'll try again tomorrow.
Just remembered something else - there were 2 timer recordings ending at the same time, so that probably explains the repeat countdowns.
Just noticed something significant - the last 45 minutes of the 1hr programme were buffered up on the pc, so maybe there was no streaming going on!More of a download...
I did the test by streaming a live-channel, so no chance of getting ahead of things there (if there were on-line bookies would be a dying breed).
Just tried a stream of a recording with vlc, and there's no indication that it buffers that much.
The box only counts things as remote streamers if they still have port 8001 open.
Just remembered something else - there were 2 timer recordings ending at the same time, so that probably explains the repeat countdowns. Which could be avoided if that screen were given a (unique) name....
Streaming live tv works ok. No shutdown when timed recording ends.
Port 8001 isn't being used (or showing up) for recordings streaming using openwebif or kodi fire tv.
Netstat -n shows them using port 80.
OpenWebif using all defaults.
Last login: Tue Feb 2 09:04:07 GMT 2016 on pts/0
root@et10000:~# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 127 et10000et10000.home:telnet xx.home:55273 ESTABLISHED
root@et10000:~# # openwebif only
root@et10000:~# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 et10000et10000.home:http xx.home:55274 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55275 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55276 ESTABLISHED
tcp 0 127 et10000et10000.home:telnet xx.home:55273 ESTABLISHED
root@et10000:~# # openwebif + tv stream
root@et10000:~# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 et10000et10000.home:8001 xx.home:55283 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55274 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55275 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55280 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55281 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55276 ESTABLISHED
tcp 0 83 et10000et10000.home:telnet xx.home:55273 ESTABLISHED
root@et10000:~# # openwebif + recording stream
root@et10000:~# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 et10000et10000.home:http xx.home:55290 ESTABLISHED
tcp 0 650236 et10000et10000.home:http xx.home:55296 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55289 ESTABLISHED
tcp 0 0 et10000et10000.home:http xx.home:55276 ESTABLISHED
tcp 0 127 et10000et10000.home:telnet xx.home:55273 ESTABLISHED
root@et10000:~# recording streamed via kodi on fire tv (uses SMB sharing)
tcp 0 127 et10000et10000.home:telnet xx.home:55273 ESTABLISHED
tcp 0 32831 et10000et10000.home:microsoft-ds kindle-xxxx.home:55432 ESTABLISHED
Port 8001 isn't being used (or showing up) for recordings streaming using openwebif or kodi fire tv.Not sure what you mean by "streaming using openwebif only". When I stream using openwebif a helper app (vlc in my case) gets fired up to do the work. I can't think of any other way to stream.
As for kodi fire tv; it isn't streaming: it's reading via a network file system. The only way to handle that would be to get the code to run an external script and check the exit status. This could check for various things (NFS or CIFS file-system in use, a user logged in via telnet or ssh, FTP in use, ....)
Not sure what you mean by "streaming using openwebif only". When I stream using openwebif a helper app (vlc in my case) gets fired up to do the work. I can't think of any other way to stream.
To be fair, I didn't actually say that.
The telnet session quote does have the word "only" in it because I had only just started openwebif at that point in time.
When I run openwebif, an app gets fired up to do the work for me as well.
I guess I don't understand what streaming means.
If I stream (transcoded) from OpenWebif, then port 8001 does get used, but I've yet to get VLC, or anything else, to play the video.
PC version of VCL is happy to play....
#EXTM3U
#EXTVLCOPT--http-reconnect=true
#EXTINF:4077,Call the Midwife
http://192.168.1.101:80/file?file=/media/hdd/movie/20160131%201958%20-%20BBC%20ONE%20HD%20-%20Call%20the%20Midwife.ts
but not this.....
#EXTM3U
#EXTVLCOPT--http-reconnect=true
#EXTINF:4077,Call the Midwife
#EXTVLCOPT:program=17540
htt://192.168.1.101:8001/file?file=/media/hdd/movie/20160131%201958%20-%20BBC%20ONE%20HD%20-%20Call%20the%20Midwife.ts?bitrate=400000?width=85 4?height=480?aspectratio=2?interlaced=0
root@et10000:~# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 520/smbd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 495/dropbear
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 520/smbd
tcp 0 0 :::8001 :::* LISTEN 605/enigma2
tcp 0 0 :::139 :::* LISTEN 520/smbd
tcp 0 0 :::80 :::* LISTEN 605/enigma2
tcp 0 0 :::21 :::* LISTEN 536/vsftpd
tcp 0 0 :::22 :::* LISTEN 495/dropbear
tcp 0 0 :::23 :::* LISTEN 532/telnetd
tcp 0 0 :::445 :::* LISTEN 520/smbd
udp 0 0 192.168.1.255:137 0.0.0.0:* 522/nmbd
udp 0 0 192.168.1.101:137 0.0.0.0:* 522/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 522/nmbd
udp 0 0 192.168.1.255:138 0.0.0.0:* 522/nmbd
udp 0 0 192.168.1.101:138 0.0.0.0:* 522/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 522/nmbd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 544/avahi-daemon: r
udp 0 0 0.0.0.0:49009 0.0.0.0:* 544/avahi-daemon: r
root@et10000:~#
but not this.....That's because it's an illegal HTTP request (it's getting a 400 error back).
The URI has to many "?" in it. The first one indicates "here are the parameters". After that something else should be used (usually &, but Perl CGI also allowed ;, as otherwise you could get really confused writing HTML and wondering whether your &'s needed to be &'s).
There was a slight typo in my last post. htt should have read http. I don't know if that had any effect.
#EXTM3U
#EXTVLCOPT--http-reconnect=true
#EXTINF:4077,Call the Midwife
#EXTVLCOPT:program=17540
http://192.168.1.101:8001/file?file=/media/hdd/movie/20160131%201958%20-%20BBC%20ONE%20HD%20-%20Call%20the%20Midwife.ts?bitrate=400000?width=85 4?height=480?aspectratio=2?interlaced=0
I've tried changing all but the first "?" to "&", but nothing happens.
There was a slight typo in my last post. htt should have read http. I don't know if that had any effect.It did, but I'd fixed that in my tests...
I've tried changing all but the first "?" to "&", but nothing happens.Well, something does, but nothing that vlc shows up.
You now get a 200 OK result, but the streaming process (if it's anything like mine) runs out of write buffers before it can return anything.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.