![]() I don't know if there are any side effects on disconnecting the dbus BEFORE the thread stop. DBus responds with the (no longer) fuzzy message. ![]() The dbus_connection_send_with_reply_and_block() than times out after the DBus default timeout value (25 seconds) the main loop is already gone, so no events handling anymore. hopefully just the guy who solved this (one?) nagging stop issue.Ībout my fuzzy message, it is from the dbus system.Īpparently when pressing too many 'q'uit characters, the Keyboard::send_action() can be called JUST AFTER the first 'q' one (which breaks the main while loop). ![]() I changed the Keyboard::Close() I'm not a hero. I'm also tend to say there is the dbus somewhere in between, the fuzzy message. So omxplayer seems to 'hang' but actually the while getchar() != EOF is every time evaluated true, and true means keep looping and looping and looping.until you hit CTRL C (=SIGINT which aborts omxplayer). Also a blocking getchar() NEVER returns an EOF character, because it never runs out of input. Pressing a key on the keyboard, a terminal ECHO'es them on the screen and a return key moves the cursor to the beginning of the next line on the screen. When getchar() is a blocking getchar(), it simply waits for a return key (or '\n' input) before it returns. When it kicks in AFTER the back-to blocking mode switch and it runs into the getchar().well you get your black screen, your no play end, your no response back to shell scripts, etc. The race is with the Keyboard::Process(). My guess is that the terminal restore is completed (sometimes, as race conditions tend to do) BEFORE the Keyboard thread is actually stopped. Now that I am zooming in into the Keyboard::Close(). I noticed this by just pressing a key and saw that the terminal echo'ed the character on the screen. In this 'hanging' situation omxplayer standard input was actually switched back from non-blocking to blocking mode. I noticed however that omxplayer isn't actually hanging (in the sense of being crashed). The investigation of this quitting issue lead to the same conclusion as made in issue #181: closing the keyboard causes omxplayer to hang. There I found out that by simply 'q'uitting omxplayer, it hangs or gives a fuzzy message (see #211). Thanks for reminding me to an issue I stumbled upon when investigating issue #211. V:PortSettingsChanged: interlace:0 deinterlace:0 anaglyph:0 par:nan layer:0 Tvservice-client: Failed to connect to TV service: -1 V:PortSettingsChanged: interlace:0 deinterlace:0 anaglyph:0 par:1.00 layer:0 Subtitle count: 0, state: off, index: 1, delay: 0 Video codec omx-h264 width 1040 height 450 profile 100 fps 29.970030Īudio codec aac channels 2 samplerate 48000 bitspersample 16
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |