WebControl

[Twilight]

offensichtlich hast du die 8000 verwendet, also bei deinem externen profil mußt du die 1413 durch 8000 ersetzen...(falls die 8000 auf die 1413 mit der ip deines receivers umgeleitet wird)

twilight

[Homer]

Port 8000 ist für WebControl, Port 1413 für TMS Remote.

Viele Grüße
Homer

[jkIT]

Das ist ja interessant, dass es doch gehen könnte. Das musste ich gleich nochmal ausprobieren. Hier die Eingaben in einem neuen Profil:
Toppy-IP: >http/i]//[my.dynname].dyn.cc<

"http://" gehört nicht zur Adresse, sondern bezeichnet das verwendete Protokoll, nämlich http zum abrufen von Webseiten.
Gib hier nur die reine Adresse an:

Code: Alles auswählen

[my.dynname].dyn.cc

In der FritzBox sind allerdings seit langem folgende Portforwardings eingestellt (und funzen perfekt):
Bezeichnung | Protokoll | IP-Adresse im Internet | Port extern vergeben
Topfield | TCP | (von FB vergeben) | 90
TMS-FTP | TCP | (von FB vergeben) | 91
TMS-Remote | TCP | (von FB vergeben) | 8000

Wo steckt der Fehler?

Es fehlt das Portforwarding des TMSRemote Ports 1413 an den Topfield (benutzt auch "TCP").

[Hemingway]

Eure Hinweise habe ich wie folgt umgesetzt:

1. Im Haus erreiche ich den Topf ...
a) mit TMSRemote (standalone) mit dem Profil [Toppy IP: >192.168.178.50< | Port: 1413 | password: Test] und
b) mit WebControl/Browser sowohl mit >http://192.168.178.50:8000/index.html#controlpage< als auch mit >...#tmsremote<.

2. Portforwarding in der FritzBox:
Bezeichnung | Protokoll | Port an Gerät | Port extern vergeben
a) Topfield | TCP | 80 bis 80 | 90
b) TMS-FTP | TCP | 21 bis 21 | 91
c) TMS-Remote | TCP | 1413 bis 1413 | 8000

3. Damit erreiche ich den Topf übers Internet ...
a) mit TMSRemote (standalone) mit dem Profil [Toppy IP: >my.dyn.cc< | Port: 8000 | password: Test],
b) aber jetzt nicht mehr mit WebControl/Browser >http://my.dyn.cc:8000/index.html#controlpage< bzw. >...#tmsremote<.

Wahrscheinlich muss ich dafür noch ein viertes Portforwarding einrichten - aber wie, wo der Port 8000 doch schon vergeben ist?
d) TMS-WebControl | TCP | ???? bis ???? | ????

[Homer]

a) mit TMSRemote (standalone) mit dem Profil [Toppy IP: >my.dyn.cc< | Port: 1413 | password: Test],
c) TMS-Remote | TCP | 1413 bis 1413 | 1413
d) TMS-WebControl | TCP | 8000 bis 8000 | 8000

Viele Grüße
Homer

[roger.stijfs]

Hi,

Correct:

c) TMS-Remote | TCP | 1413 bis 1413 | 1413

And add:

For Webcontrol:

d) WebControl | TCP | 8000 bis 8000 | 8000

For Webcontrol-EPGSearch:

e) EPGSearch | TCP | 8800 bis 8800 |8800

For TMS-Remote Live (That is for the LiveServer.TAP and TMSRemoteLive):

f) LiveServer | TCP | 1419 bis 1419 | 1419


That's it, I think.
Greetings,

[roger.stijfs]

Oh, Homer answered already.

Use the extra e) and f).

Greetings.

[Hemingway]

I'm so impressed what you can do !

And Roger, dankuwel for the tips regarding EPG search and TMSRemoteLive! I've already installed both and they work perfectly, including importing all the Toppy searches. Incredible!

After correcting the Portforwarding settings, all these options work smoothly:
- home: TMSRemote app, TMSRemoteLive app, WebControl including TMSRemote;
- internet: TMSRemote app, TMSRemoteLive app, WebControl

... but the TMSRemote module within WebControl does not connect. After clicking "connect" the row with the "Hide OSD" and "Direct" buttons briefly appears and then disappears again. After that the whole window hangs a while before clicking leads to actions again.
Maybe the TMSRemoteLive module/function is not configured correctly yet ...
[Edit] Please let me know what logs you need ...

[roger.stijfs]

Hi,

And Roger, dankuwel for the tips regarding EPG search and TMSRemoteLive! I've already installed both and they work perfectly, including importing all the Toppy searches. Incredible!

. But most credits go to jkIT and DMC. I'm just the Dutch-translater.

... but the TMSRemote module within WebControl does not connect. After clicking "connect" the row with the "Hide OSD" and "Direct" buttons briefly appears and then disappears again. After that the whole window hangs a while before clicking leads to actions again.

Did you fill in the portnumber 1413 at the port-parameter in the gearbox, that is apearing when opening webcontrol's tmsremote page?
At my place, if this parameter box is empty, only local connection is working.

Maybe the TMSRemoteLive module/function is not configured correctly yet ...

TMSRemoteLive is not a webcontrol module. It is a windows application.
Within this application, you create a connection profile.
This is the same as tmsremote but instead of two portnumbers (1413 & 1415), you fill in a third one: Live: 1419.
TMSRemoteLive works together with LiveServer.TAP.
Installing this TAP will also create a plugin in webcontrol, the famous STREAM button.
LiveServer.Tap must be in autostart for correct working with port 1419.

[Edit] Please let me know what logs you need ...

You may post a webcontrol-log zipfile here, but I do not have the scills to investigate it. I can only read it.
Maybe the known programmers can do the investigation, but that is something, they have to decide for themselves.

If you go some pages back, you'll find more info on epgsearch and liveserver.

Greetings.

[roger.stijfs]

Hi,

@jkIT, @DMC. I hope you're all okl.

Anny thoughts on "block this timer" function in timerspage?

Why do I ask?

I sometimes delete timers by webcontrol.
Next day they are back.
SE programs the timers again, cause they were not blocked.

Greetings.

[Hemingway]

Good evening,

this is still the state of affairs: All these connect perfectly to the Toppy:
- home: TMSRemote app, TMSRemoteLive app, WebControl including TMSRemote module;
- internet: TMSRemote app, TMSRemoteLive app, WebControl BUT NOT the TMSRemote module.

When I click on "Connect" in WebControl's TMSRemote module (WC_TMSR_1.jpg), the other icons on that bar appear very briefly (WC_TMSR_2.jpg - a real snapshot!) then disappear again and there is no connection. After that the whole window hangs a while before clicking leads to actions again.

In the meantime I found out that as a consequence of this click the Toppy seems to reset somehow but I can't find out what exactly it does. Anyway there seems to be no picture on the TV during much of this hanging period, recordings end and are resumed with a new .rec file after the hang. To me the period of interruption seems too short for a complete shutdown plus restart, but who knows ...

For some more information that might help to find the cause why the WebControl-TMSRemote module behaves so strangely I append WebControl.log_0304.txt (slightly edited and with 3 comments).

Unfortunately I'll be away from home for about ten days starting Monday, so please don't wonder if I don't respond immediately to any posts.

Regards, Hemingway

[jkIT]

Good evening,

this is still the state of affairs: All these connect perfectly to the Toppy:
- home: TMSRemote app, TMSRemoteLive app, WebControl including TMSRemote module;
- internet: TMSRemote app, TMSRemoteLive app, WebControl BUT NOT the TMSRemote module.

When I click on "Connect" in WebControl's TMSRemote module (WC_TMSR_1.jpg), the other icons on that bar appear very briefly (WC_TMSR_2.jpg - a real snapshot!) then disappear again and there is no connection. After that the whole window hangs a while before clicking leads to actions again.

In the meantime I found out that as a consequence of this click the Toppy seems to reset somehow but I can't find out what exactly it does. Anyway there seems to be no picture on the TV during much of this hanging period, recordings end and are resumed with a new .rec file after the hang. To me the period of interruption seems too short for a complete shutdown plus restart, but who knows ...

Oh, das sieht nach einem Reboot aus.
Also nicht während wichtiger Aufnahmen weiter experimentieren .

For some more information that might help to find the cause why the WebControl-TMSRemote module behaves so strangely I append WebControl.log_0304.txt (slightly edited and with 3 comments).

Deine 3 Comments beziehen sich auf die Suche nach den Dateien "custom.css" in den Modul-Verzeichnissen. Das sind keine Fehler, sondern nur Prüfungen, ob diese Dateien existieren. Sie werden nicht benötigt, diese Meldungen können ignoriert werden.

Ansonsten sieht man im Log nur, dass WebControl durch den Reboot neu gestartet wurde.
Evtl. kann man im TMSRemote.log was erkennen?

[jkIT]

Any thoughts on "block this timer" function in timerspage?

Why do I ask?

I sometimes delete timers by webcontrol.
Next day they are back.
SE programs the timers again, cause they were not blocked.

Greetings.

Its not possible, because SmartEPG is using its own timer management.

[Hemingway]

Hallo jkIT,

anbei der TMSRemote.log des Events. Hoffentlich verrät er mehr.

Wahrscheinlich ist beides hier irrelevant, aber mir sind noch 2 Sachen aufgefallen:
- WebControl-Network.log (in ProgramFiles/Settings/WebControl/) ist leer (0 Bytes).
- In der aktuellen TMSRemote_Network.ini (in ProgramFiles/Settings/TMSRemote/) fehlt im Vergleich zu deren Version vom 26.2. die Zeile mit der lokalen IP:
MAXPENDING=1
ADDRESS=192.168.178.32
BUFFSIZE=65535
PORT=1413
PORTVFD=1415
Password=Test

Grüße,
Hemingway

[jkIT]

Den Eintrag ADDRESS hab ich auch nicht.

Im Log sieht man, dass die Verbindung von der Webseite klappt. Auch die Authentifizierung scheint zu gehen. 10 sec. später wird die Verbindung hart unterbrochen, denn normalerweise steht vor "Closing connection" noch ein Eintrag mit "received closing frame".

Leider habe ich keine Idee, was da passiert.
Steht noch was erhellendes auf der WebControl Log Seite im Browser, oder in der Browser Console?

[Hemingway]

Hab WC > TMSRemote jetzt in Chrome und mit index-dev.html gestartet. Klick auf "verbinden" löst (natürlich) auch hier den Toppy-Reset aus.

Die WebControl Log Seite im Browser zeigt nur das leere Kästchen.
Die Console meldet:

Failed to load resource: the server responded with a status of 404 (NOT FOUND)
channelsort.js Failed to load resource: the server responded with a status of 404 (NOT FOUND)
http://My.Dyn.Dns.cc:8000/modules/menum ... 8677378709 Failed to load resource: the server responded with a status of 404 (NOT FOUND)
tmaChannel.js:152 TmaChannel.getEvents: 13 ms
http://My.Dyn.Dns.cc:8000/modules/confi ... 8677378714 Failed to load resource: the server responded with a status of 404 (NOT FOUND)
jquery-1.11.3.js:9664 GET http://My.Dyn.Dns.cc:8000/modules/tmsre ... 8677378728 404 (NOT FOUND)
send @ jquery-1.11.3.js:9664
ajax @ jquery-1.11.3.js:9215
loadCss @ tmaModuleManager.js:538
(anonymous) @ tmaModule.js:270
fire @ jquery-1.11.3.js:3148
fireWith @ jquery-1.11.3.js:3260
deferred.(anonymous function) @ jquery-1.11.3.js:3350
fire @ jquery-1.11.3.js:3148
fireWith @ jquery-1.11.3.js:3260
deferred.(anonymous function) @ jquery-1.11.3.js:3350
(anonymous) @ tmaModuleManager.js:640
fire @ jquery-1.11.3.js:3148
fireWith @ jquery-1.11.3.js:3260
done @ jquery-1.11.3.js:9314
callback @ jquery-1.11.3.js:9718
index-dev.html#tmsremote:1 This page includes a password or credit card input in a non-secure context. A warning has been added to the URL bar. For more information, see https://goo.gl/zmWq3m.
VM102:250 WebSocket - status 0
VM102:250 Welcome - status 1
VM102:250 Disconnected - status 3
jquery-1.11.3.js:9664 GET http://My.Dyn.Dns.cc:8000/api?function= ... action=get! net::ERR_CONNECTION_REFUSED

[DeltaMikeCharlie]

I sometimes delete timers by webcontrol.
Next day they are back.
SE programs the timers again, cause they were not blocked.

That would involve making SmartEPG capable of receiving commands via the WebControl TAP and writing a SmartEPG web front end. I have, however, thought of a relatively simple option that would involve very little modification to SE and achieve the desired result.

In your case, the timer comes back because it was deleted, not blocked. SE just recreates the timer on the next search.

Perhaps, we could rename the timer instead of deleting it, but rename it in a special way that SE could recognise and then block that timer. If we have a timer called "timer.rec", perhaps if it was renamed to something like "--timer.rec" and SE could recognise that timer name as a command to block "timer.rec". The "--" prefix would become the command to block any timer.

We would still need the SE authors to agree the best way to achieve this, but the principle could be worth investigating if the feature would be useful to enough users.

[roger.stijfs]

Hi,

@ Hemingway: I am out. I can't help any further.

Its not possible, because SmartEPG is using its own timer management.

Ok. I did not know that.
I'll do timer blocking with TMSRemote. Open SE.. Timerpage.. select timer.. Stop-button.. OK.
That is working too.

That would involve making SmartEPG capable of receiving commands via the WebControl TAP and writing a SmartEPG web front end. I have, however, thought of a relatively simple option that would involve very little modification to SE and achieve the desired result.

In your case, the timer comes back because it was deleted, not blocked. SE just recreates the timer on the next search.

Perhaps, we could rename the timer instead of deleting it, but rename it in a special way that SE could recognise and then block that timer. If we have a timer called "timer.rec", perhaps if it was renamed to something like "--timer.rec" and SE could recognise that timer name as a command to block "timer.rec". The "--" prefix would become the command to block any timer.

We would still need the SE authors to agree the best way to achieve this, but the principle could be worth investigating if the feature would be useful to enough users.

OK! I believe you.
However, the answer to jkIT is an other way to "block timer". And is working to.
Thanks for the thinking, but I think it's to complicated.

A block timer macro may do the same, eg.:

Klicking button 'Block timer' results in:

Open en connect to tmsremote, open SmartEPG, open SE-Timerview (5),
and:

1. - Let the user do his stuf. Exitting SE and TMSRemote can be done by user!

or

2. - search the corresponding timer in timerlist, activate 'remote-control-button 'stop', (if asked: select program), 'remote control button 'OK', exit SmartEPG, Exit TMSRemote.

As always, these are my thoughts. I don't have the skills to program such actions.

Anyway, stupid ideas don't exist. Is an idea executable? Depends on something else.

Have a nice sunday.

Greetings.

[jkIT]

[quote="Hemingway"]Hab WC > TMSRemote jetzt in Chrome und mit index-dev.html gestartet. Klick auf "verbinden" löst (natürlich) auch hier den Toppy-Reset aus.

Die WebControl Log Seite im Browser zeigt nur das leere Kästchen.

Die Console meldet:

...
VM102:250 WebSocket - status 0
VM102:250 Welcome - status 1
VM102:250 Disconnected - status 3
[/quote]
Danke, leider nichts, was uns weiterhilft. Melde dich nach deiner Reise mal per Email bei mir, ich denke wir müssen tiefer graben, um dem Reboot auf die Spur zu kommen.

[jkIT]

A block timer macro may do the same, eg.:

Klicking button 'Block timer' results in:

Open en connect to tmsremote, open SmartEPG, open SE-Timerview (5),
and:

1. - Let the user do his stuf. Exitting SE and TMSRemote can be done by user!

or

2. - search the corresponding timer in timerlist, activate 'remote-control-button 'stop', (if asked: select program), 'remote control button 'OK', exit SmartEPG, Exit TMSRemote.

As always, these are my thoughts. I don't have the skills to program such actions.

The problem with such a macro is, that we don't have a simple way to get a feedback of the current state of the Toppy's OSD.