 |
@MatN Late update - the EasyCap that has markings on it of "Video DVR" online arrived and I was hoping that it is really is the same as usbtv007. Unfortunately, the system messages show it as the exact same device as the one we already had . The accompanying information says this Easy Cap can do PAL but we have not thoroughly tested it yet because discouraged by the fact that it looks the same as the first one. It is still sitting here waiting for us to try ... ! |
|
|
@MatN Thanks for the updated program - it is helpful. And, Yes, you can record from a Webcam as we have done that before. |
 |
I found two more USB video devices (webcam), and those do support EnumFrameSize. I presume CinGG should be able to record from a webcam too? Anyway, I changed my test program to show more info, I hope it is useful if someone has problems recording: it will show what the device can do. Hopefully this will diminish the requirement for the developer to have a problematic device available. Here is the TestV4l2 output of the three devices, the usb stick was set to switch to PAL mode. ========== TestV2L4 output for Easycap USB video capture stick === ./TestV4l2 PAL Current video standard id: F900 Device : /dev/video0, driver=usbtv, card=usbtv, bus_info=usb-0000:09:00.3-2, version=4.15.18 Capabilities: VIDEO_CAPTURE READWRITE STREAMING Supported formats: format 0 ="YUYV 4:2:2",pixelformat="YUYV", image format=V4L2_BUF_TYPE_VIDEO_CAPTURE, data stream type=?, framesizes: EnumFrameSizes failed with error 25: "Inappropriate ioctl for device" Device video capture standards: index, hex value, name, lines/frame, frame period, frame frequency 00, 0000B000, NTSC, 525, 1001/30000, 29.97 01, 00001000, NTSC-M, 525, 1001/30000, 29.97 02, 00002000, NTSC-M-JP, 525, 1001/30000, 29.97 03, 00008000, NTSC-M-KR, 525, 1001/30000, 29.97 04, 00004000, NTSC-443, 525, 1001/30000, 29.97 05, 000000FF, PAL, 625, 1/25, 25.00 06, 00000007, PAL-BG, 625, 1/25, 25.00 07, 00000008, PAL-H, 625, 1/25, 25.00 08, 00000010, PAL-I, 625, 1/25, 25.00 09, 000000E0, PAL-DK, 625, 1/25, 25.00 10, 00000100, PAL-M, 525, 1001/30000, 29.97 11, 00000800, PAL-60, 525, 1001/30000, 29.97 Current video standard id: FF ========== TestV2L4 output for Philips webcam === ./TestV4l2 VideoGetStandard failed with error 25: "Inappropriate ioctl for device" Device : /dev/video0, driver=pwc, card=Philips 730 webcam, bus_info=usb-0000:01:00.0-4, version=4.15.18 Capabilities: VIDEO_CAPTURE READWRITE STREAMING Supported formats: format 0 ="Raw Philips Webcam Type (New)",pixelformat="PWC2", image format=V4L2_BUF_TYPE_VIDEO_CAPTURE, data stream type=V4L2_FMT_FLAG_COMPRESSED, framesizes: type 1, 160x120 type 1, 320x240 type 1, 640x480 format 1 ="Planar YUV 4:2:0",pixelformat="YU12", image format=V4L2_BUF_TYPE_VIDEO_CAPTURE, data stream type=?, framesizes: type 1, 160x120 type 1, 320x240 type 1, 640x480 EnumVideoStandards failed with error 25: "Inappropriate ioctl for device" ========== TestV2L4 output for Logitech Quickcam Messenger webcam === ./TestV4l2 VideoGetStandard failed with error 25: "Inappropriate ioctl for device" Device : /dev/video0, driver=STV06xx, card=Camera, bus_info=usb-0000:01:00.0-4, version=4.15.18 Capabilities: VIDEO_CAPTURE READWRITE STREAMING Supported formats: format 0 ="8-bit Bayer GRGR/BGBG",pixelformat="GRBG", image format=V4L2_BUF_TYPE_VIDEO_CAPTURE, data stream type=?, framesizes: type 1, 162x120 type 1, 324x240 EnumVideoStandards failed with error 25: "Inappropriate ioctl for device" TestV4l2.C-3.7z (2,491 bytes) |
|
|
Because other people have different capture devices, it might be useful to show the output of mine. The device was in mode FF (PAL), I tried switching is to PAL-M and it ended up in mode F900 which is NTSC. === Program output === Current video standard id: FF Device : /dev/video0, driver=usbtv card=usbtv bus_info=usb-0000:09:00.3-2 version=4.15.18 Capabilities: VIDEO_CAPTURE READWRITE STREAMING Supported formats: format 0 ="YUYV 4:2:2"; pixelformat="YUYV", framesizes: EnumFrameSizes failed with error 25: "Inappropriate ioctl for device" Device video capture standards: index, hex value, name, lines/frame, frame period, frame frequency 00, 0000B000, NTSC, 525, 1001/30000, 29.97 01, 00001000, NTSC-M, 525, 1001/30000, 29.97 02, 00002000, NTSC-M-JP, 525, 1001/30000, 29.97 03, 00008000, NTSC-M-KR, 525, 1001/30000, 29.97 04, 00004000, NTSC-443, 525, 1001/30000, 29.97 05, 000000FF, PAL, 625, 1/25, 25.00 06, 00000007, PAL-BG, 625, 1/25, 25.00 07, 00000008, PAL-H, 625, 1/25, 25.00 08, 00000010, PAL-I, 625, 1/25, 25.00 09, 000000E0, PAL-DK, 625, 1/25, 25.00 10, 00000100, PAL-M, 525, 1001/30000, 29.97 11, 00000800, PAL-60, 525, 1001/30000, 29.97 Current video standard id: F900 ================== |
|
|
I changed my test program after looking at qv4l2 code (like general-tab.cpp). It now switches video modes on demand, and the switch is confirmed when using qv4l2 afterwards. The device I have enumerates a full list of standards, but if you select any of them, you only get NTSC or PAL. Some PAL standard even set it to NTSC. The way to use it is either "TestV4l2" which shows current standard and device/format details, or "TestV4l2 name" where "name" is one of the standard listed before. In this last case, it will switch the standard and retrieve it afterwards to check. So it looks my device at least only supports PAL or NTSC. Considering the USB capture thing only connect to a SCART or S-Video connector, that might be sufficient. Attached is the update test program. It looks like horizontal pixels is always 720, only the number of vertical lines varies. I wonder if it is feasible to allow querying the device in the Preferences->Recording tab, and either give a choice like qv4l2 does, or only let choose between NTSC/PAL/SECAM, although I do not know if there is any capture thing that support SECAM. TestV4l2.C-2.7z (2,078 bytes) |
|
|
@MatN Interesting test results. GG installed the qv4l2 code on a test computer based on your notes and is looking at the qv4l2 code to see if he can pick up some improvements. In the past he has had trouble finding good v4l2 code to look at. The quality of qv4l2 versus cingg shown in your png files is a lot different and he would like to get better quality if possible. Meanwhile, I have found an EasyCap that has markings on it of "Video DVR" online and am hoping that it is really the same as yours of usbtv007. Unfortunately, it is being shipped from outside the country and will not be here until June 5 (fun to try another toy, so worth the wait). We do not think the Easy Cap we have can do PAL. |
|
|
Ok, more test results, now with a VHS VCR as source. 1. Before each recording you have to use qv4l2 to set it to PAL-BG mode (did not try other modes). If you then view the input using qv4l2 you get interrupted audio, video is OK. The terminal shows many audio buffer underruns/overruns. Exit qv4l2. 2. Using CinGG, audio input usbtv, video input video0, format 720x576. Settings to PAL 576I, but change audio samplerate to 44100. The recording works, audio is fine, but the bottom half of the picture is wrong. See the two screenshots of the same scene, one from qv4l2, one from cin. Screenshots made with an external program "screenshot", came with Mint 19.3 XFCE. I did get a few audio errors on the terminal, but it sounded fine to me, although the source material is not the best to judge this. AudioALSA::write_buffer err -32(Broken pipe) at sample 2048 Conclusion for now: - CinGG obviously uses a different set video format mode than qv4l2, and apparently sets it back when it exists. Maybe this is also the reason the video bottom is wrong, almost looks like it is using the NTSC number of lines. - Audio sample rate might be important, I got errors when using 48k (which I would expect it to be). Screenshot_qv4l2.png (733,666 bytes) Screenshot_cingg-2020-02.png (463,404 bytes) |
 |
Was about to add two links I was following long after I give away my tuner card: https://git.linuxtv.org/xawtv3.git/ - you can look at this old program and also tvtime at the same addr. They supposedly use ALSA, too, for sound capture along with TV image. https://build.opensuse.org/package/show/home:wolfi323/xdtv "XdTV is a software to watch, record & stream TV" I hope testing same device with various open-source apps will help to determinate what best course of action will be for Cinelerra .... |
|
|
@MatN About: "Is it normal that many threads are waiting for radeonsi_drv.so ?" GG thinks these might be Radeon card lock errors you see in journalctl. About: "AudioALSA::write_buffer err -32(Broken pipe) at sample 2048 ** dump complete Segmentation fault (core dumped)" GG says the dump looks like something is trying to open an output device but it is stuck doing so -- i.e. the output devie looks broken (are speakers auto-console?) Maybe jiggle the output by picking a different device will work. |
|
|
for 3d part of graphics stack look at mesa3d, nowadays (and on radeonSI family of cards/GPUs) even 2D accel in X provided via 3d driver..... https://cgit.freedesktop.org/mesa/mesa/ - I have this open alongside CinGG and few other projects (as someone who tries to live on leading edge here, because ..regressions happen, without reporting they easily hit releases, and took a lot of time to fix first upstream, and then in distros). You can try to hang around at irc.freenode.net #radeon, I definitely got some help there in the past. |
|
|
After the crash, I found in "journalctl -b" output quite a few red lines of: Stack trace of thread 2961: #0 0x00007fe15a9c19f3 futex_wait_cancelable (libpthread.so.0) 0000001 0x00007fe14f163a0b n/a (radeonsi_dri.so) 0000002 0x00007fe14f163607 n/a (radeonsi_dri.so) 0000003 0x00007fe15a9bb6db start_thread (libpthread.so.0) #4 0x00007fe155a1688f __clone (libc.so.6) Is it normal that many threads are waiting for radeonsi_drv.so ? I run (for this test) kernel 4.15.0-88-generic , video hardware is Ryzen 2400G, driver amdgpu . |
|
|
Oops, found a crash. I was testing earlier without recording audio. When I switched on audio, Alsa device usbtv (and to make sure use qv4l2 before each recording), CinGG statrs recording, but then crashes with a segv. This is very likely Alsa related, because qv4l2 also reports buffer underruns or some such, and you hear ticks. The cinGG dump is attached, this is the 2020-02 version for Mint 19. Terminal shows: v4l2 s_fmt 720x576 YUYV ** segv at 0x56221e814218 in pid 2914, tid 3964 writing debug data to /tmp/cinelerra_2914.dmp lock_items: 27 lock_frees: 6 AudioALSA::write_buffer err -32(Broken pipe) at sample 2048 ** dump complete Segmentation fault (core dumped) cinelerra_2914.dmp.7z (13,014 bytes) |
|
|
Interesting. I got it working without changes if I use qv4l2 to set it to PAL-BG mode and start viewing. That gives you a black screen and audio ticks. If you then stop it it stays in PAL-BG mode. I then can record using CinGG (using setting for PAL) if I choose the Video4Linux2 driver (the first) , not the jpeg or mpeg versions. Those fail. With the first driver the terminal window shows: DeviceV4L2Base::v4l2_open pixels="YUYV"; res="" v4l2 s_fmt 720x576 YUYV I hope to hook up a VCR tomorrow and test real recording from tape. @v4t, can you test if it works for you if you use qv4l2 first to set the device in PAL mode? |
|
|
EasyCap device arrived and we tested it and the way gg got it to work was by using the Video In, Record Driver "Video4Linux2 JPEG" -- the device provided no probe data. As predicted it is not the exact device you are using but hopefully it has the same results. Packaging reads: Easy CAPture USB 2.0 Video Adapter with Audio (only $7.00) Model # DC60. Attached is a png showing Cinelerra setup. Output on startup window while playing: ----------------------------------------------------------- DeviceV4L2Base::v4l2_open pixels="MJPG"; res="480x320 640x480 720x480" DeviceV4L2Base::v4l2_open pixels="YUYV"; res="480x320" v4l2 s_fmt 640x480 MJPG DeviceV4L2Base::v4l2_open VIDIOC_S_STD: Inappropriate ioctl for device DeviceV4L2Base::v4l2_open VIDIOC_G_JPEGCOMP: Inappropriate ioctl for device DeviceV4L2Base::v4l2_open VIDIOC_S_JPEGCOMP: Inappropriate ioctl for device [Detaching after vfork from child process 6539] Output from "dmesg" for EasyCap - Model # DC60: ------------------------------------------------------------------------- [ 748.560775] usb 3-1.2: new high-speed USB device number 8 using xhci_hcd [ 748.574296] usb 3-1.2: New USB device found, idVendor=534d, idProduct=0021, bcdDevice= 1.21 [ 748.574303] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 748.574307] usb 3-1.2: Product: AV TO USB2.0 [ 748.574310] usb 3-1.2: Manufacturer: MACROSILICON [ 748.574313] usb 3-1.2: SerialNumber: 20150130 [ 748.635600] hid-generic 0003:534D:0021.0008: hiddev97,hidraw0: USB HID v1.10 Device [MACROSILICON AV TO USB2.0] on usb-0000:16:00.3-1.2/input4 [ 748.698491] mc: Linux media interface: v0.10 [ 748.727360] videodev: Linux video capture interface: v2.00 [ 748.796533] usbcore: registered new interface driver snd-usb-audio [ 748.796660] uvcvideo: Found UVC 1.00 device AV TO USB2.0 (534d:0021) [ 748.796876] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [ 748.797204] uvcvideo 3-1.2:1.0: Entity type for entity Processing 2 was not initialized! [ 748.797212] uvcvideo 3-1.2:1.0: Entity type for entity Camera 1 was not initialized! [ 748.797353] usbcore: registered new interface driver uvcvideo [ 748.797356] USB Video Class driver (1.1.1)[ 3982.626522] retire_capture_urb: 7 callbacks suppressed [ 3982.747515] usb 3-1.2: USB disconnect, device number 8 [ 4007.286371] usb 3-1.2: new high-speed USB device number 9 using xhci_hcd [ 4007.302726] usb 3-1.2: New USB device found, idVendor=534d, idProduct=0021, bcdDevice= 1.21 [ 4007.302732] usb 3-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4007.302736] usb 3-1.2: Product: AV TO USB2.0 [ 4007.302740] usb 3-1.2: Manufacturer: MACROSILICON [ 4007.302743] usb 3-1.2: SerialNumber: 20150130 [ 4007.354826] uvcvideo: Found UVC 1.00 device AV TO USB2.0 (534d:0021) [ 4007.354939] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround. [ 4007.355252] uvcvideo 3-1.2:1.0: Entity type for entity Processing 2 was not initialized! [ 4007.355256] uvcvideo 3-1.2:1.0: Entity type for entity Camera 1 was not initialized! [ 4007.420828] hid-generic 0003:534D:0021.0009: hiddev97,hidraw0: USB HID v1.10 Device [MACROSILICON AV TO USB2.0] on usb-0000:16:00.3-1.2/input4 @MatN The program you attached is very useful. The dump you attached has too little information for analysis. If you ever have time and want to get more data, compile a debuggable CinGG, make sure gdb is installed, run as root in debug mode, and see if you can get that dump again.
EasyCap_setup.png (172,288 bytes) |
|
|
I think the enumframesize failure is not due to programming, but that the device/driver does not support it, because program v4l2-ctl doesn't show it either: v4l2-ctl --list-formats-ext ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Pixel Format: 'YUYV' Name : YUYV 4:2:2 This command should show framesizes too, per format. |
|
|
I made a small program (attached) to locate the error. It seems to fail trying to enumerate frame sizes, and I don't understand why. Program output (on Mint 19.3) is below, the version is the same on Mint 18.3. Device : /dev/video0, driver=usbtv card=usbtv bus_info=usb-0000:09:00.3-2 version=4.15.18 Capabilities: VIDEO_CAPTURE READWRITE STREAMING Supported formats: format 0 ="YUYV 4:2:2"; pixelformat="YUYV", framesizes: EnumFrameSizes failed with error 25: "Inappropriate ioctl for device" VideoStandards per index: 0 B000: NTSC-M NTSC-M-JP NTSC-M-KR 1 1000: NTSC-M 2 2000: NTSC-M-JP 3 8000: NTSC-M-KR 4 4000: NTSC-443 5 FF: PAL-B PAL-B1 PAL-G PAL-H PAL-I PAL-D PAL-DI PAL-K 6 7: PAL-B PAL-B1 PAL-G 7 8: PAL-H 8 10: PAL-I 9 E0: PAL-D PAL-DI PAL-K 10 100: PAL-M 11 800: PAL-60 TestV4l2.C.7z (1,702 bytes) |
|
|
Tested again as we had located a PAL dvd and an old APEX-1200 dvd player that we were hoping to get working. Unfortunately we discovered that the APEX had had its firmware upgraded and would only read Region 1 so no PAL. However, the NTSC recorded both Video and Audio using a Hauppauge device and we had no problems with it. Attached shows our Cinelerra setup and you can see the recorded media loaded in the timeline and displayed in the compositor. We have ordered an EasyCap and maybe it will help with diagnosis but my understanding is that EasyCap changes chip and firmware frequently and still call it the same name. Probably people have moved on from this problem but you never know. usb_capture.png (407,543 bytes) |
|
|
is there possibility switch at line 540 get sets norm to default case (default: std_id = V4L2_STD_NTSC_M; break;), because video_channel->norm at this point in time actually "0" ? |
|
|
I had little time to debug it, but noticed there are two weird things that I don't understand, in source module device4lbase.C: - Line 310 has a loop going through the available formats using VIDIOC_ENUM_FMT. This first (and only one) it gets is format V4L2_PIX_FMT_YUYV . For this format, it then tries to get allowed frame sizes using VIDIOC_ENUM_FRAMESIZES , but that call immediately returns an error; it should return at least one valid frame size if I understand the kernel docs correctly. - Line 429 and following do a VID_IOC_G_FMT which returns 720x480 YUYV . It then does a VID_IOC_S_FMT with values 720x576 YUYV, but the return values from that are again the original values, so it does not actually change the format. |
 |
I have both VLC and Cin Sound...sorry |
|
|
#MatN, I have both VLC and Cin Ton. Unfortunately with Cin no picture, however, Cin with the setting 720x576 YUYV shows a green background. There is probably not much missing to success. |
|
|
I have exactly the same video grabber. And dusted off an old VHS recorder. With that: - VLC capture works (but no sound, could be a settings). - ffplay /dev/video0 works, again with no sound. It reports: Input #0, video4linux2,v4l2, from '/dev/video0':B sq= 0B f=0/0 Duration: N/A, start: 9079.978687, bitrate: 165888 kb/s Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 720x576, 165888 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc - cin recording starts, then some crashy noise from the speakers, then CinGG crashes. Dump file attached. The following info on the terminal from which CinGG was started: Cinelerra Infinity - built: Jan 31 2020 11:52:19 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. DeviceV4L2Base::v4l2_open pixels="YUYV"; res="" v4l2 s_fmt 720x576 YUYV ** segv at 0x55f3a05722d8 in pid 6995, tid 7070 writing debug data to /tmp/cinelerra_6995.dmp lock_items: 25 lock_frees: 4 AudioALSA::write_buffer err -32(Broken pipe) at sample 4096 ** dump complete Segmentation fault (core dumped) I did set the following in CinGG: Preferences->recording: format 720x756 PAL, frame rate 50. Left audio driver at default, should have been usbtv which was in the dropdown list. Repeating the exercise with the usbtv audio driver gives the same error as 4vt. Hope this helps. cinelerra_6995.dmp (76,474 bytes) |
|
|
> do not understand dev: adaptor open failed I think this comes from https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/devicev4l2base.C;h=9e3fd129ac023ff88c2792009b0798abfc01be59;hb=HEAD 451 iwidth = v4l2_params.fmt.pix.width; 452 iheight = v4l2_params.fmt.pix.height; 453 if( iwidth != best_width || iheight != best_height ) 454 { 455 printf("DeviceV4L2Base::v4l2_open set geom %dx%d != %dx%d best_geom\n", 456 iwidth, iheight, best_width, best_height); 457 return 1; 458 } I guess I tries to set NTSC framesize anyway, even if capture resolution was set to PAL (720x576) ? |
|
|
DeviceV4L2Base::v4l2_open set geom 720x480 != 720x576 best_geom DeviceV4L2Base::open_dev failed DeviceV4L2Base::open_dev: adaptor open failed DeviceV4L2Base::v4l2_open pixels="YUYV"; res="" v4l2 s_fmt 720x576 YUYV I do not understand dev: adaptor open failed Screenshot_YUYV.png (528,896 bytes) |
|
|
Hm, I think this confirms device send raw YUY2 data, and not pre-compressed MPEG/JPEG stream. Try to set input driver to just "YUYV webcam" ? |
|
|
@ Andrew-R Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski <[email protected]> comment: first try, more to come ;-) Selected device: usbtv Capabilities: video capture read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK; 10 = PAL-M; 11 = PAL-60; 12 = SECAM; 13 = SECAM-B; 14 = SECAM-G; 15 = SECAM-H; 16 = SECAM-DK; 17 = SECAM-L; 18 = SECAM-Lc; inputs: 0 = Composite; 1 = S-Video; Current input: 0 Current format: YUYV Selected input hasn't got a tuner! v4l2: ioctl set mute failed: Invalid argument ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video Movie-Aspect is undefined - no prescaling applied. VO: [vdpau] 720x576 => 720x576 Packed YUY2 Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) ========================================================================== Audio: no sound |
|
|
@ Andrew-R lsusb says: Bus 003 Device 005: ID 1b71:3002 Fushicai USBTV007 Video Grabber [EasyCAP] |
|
|
Sorry I'm reporting so late. I got an unexpected visit until yesterday. Error Log in Terminal: DeviceV4L2Base::v4l2_open pixels="YUYV"; res="" DeviceV4L2Base::v4l2_open MPEG Treiber und best_format nicht MPEG (YUYV) DeviceV4L2Base::open_dev failed DeviceV4L2Base::open_dev: adaptor open failed DeviceV4L2Base::v4l2_open pixels="YUYV"; res="" DeviceV4L2Base::v4l2_open MPEG Treiber und best_format nicht MPEG (YUYV) DeviceV4L2Base::open_dev failed |
|
|
Interesting.. is there possibility this usbtv device actually sends *uncompressed* (yuv)) stream via usb? In this case I think v4l2 capture method should NOT be set to v4l2 mpeg - because this implies device sends TS stream over usb ..... Can you try mplayer/mpv (?) and see what they logs to terminal? https://linuxtv.org/wiki/index.php/Easycap - if it was one of .. those ..... you are lucky it worked at all :} |
|
|
Watched your video and GG set up a test case here (V4l2 Mpeg svideo) which worked -- we see video and hear audio. He checked your settings and they look correct and are what is expected. He thinks that the audio you hear may be from Alsa. We used it with NTSC as we have never debugged with PAL since we have no way to test that here in the United States. Start the program from a command line terminal and watch the log messages. Sometimes this helps. |
- Anonymous
