Stable: 2.5.2
Development: 2.6-alpha3
Hi everyone,
I'm running MOC on an Raspberry Pi 3 with the latest raspbian release from within a Python script.
Currently I'm building a very simple audio player working like this:
- scan album title from a qr code (this is a process within a while loop)
- if the qr code is read successfully, play a confirmation tone and start playing album from sc card
- otherwise play an error tone
This works quite well when the engine is running. But on startup I'm expierencing a very curios behavior:
- when I tell the Pi to scan a code,
- the code is scanned, the confirmation tone is played 3 to 5 times (this part is not within the loop)
- another tone that sounds like an explosion is played
- and finally the album is played
After 2 or 3 times with this behaviour it seems the Pi and Mocp is "ready" and everything works fine ...
The explosion sound is not set by me - is this a standard sound by moc?
Has anyone else already expierenced such a behaviour and knows how to fix that?
Any help is appreciated.
Thanks!
tomaszg
Tue, 2016-11-29 10:42
Permalink
I didn't run MOC on RPi, but
I didn't run MOC on RPi, but I run it on OpenWRT router and I didn't hear anything similar to what you describe. You might try to record debug log for MOC (mocp -D) and see what happens when the explosion sound is heard.
I must say I like your idea of controlling MOC via qrcodes. I'm still struggling with good ways to control my OpenWRT MOC (other than via ssh) and it looks interesting. Do you just use a webcam, or some dedicated code reader?
RasPi
Tue, 2016-11-29 12:04
Permalink
Hi,
Hi,
it's just a simple USB webcam I bought on Ebay for 5 Euro - it was the cheapest device I found and works via plug and play. I also found other projects using RFID, so maybe that might be another handy way for you.
Currently I run moc via pyhton script and therefore don't use a frontend. How can I view the debug log when I run moc via mocp -D?
tomaszg
Tue, 2016-11-29 12:08
Permalink
The log is just recorded to
The log is just recorded to the file mocp_server_log in the working directory. It can be quite lengthy but some hints might be hidden there.
RFID tags are also a good idea - but in both cases there is a problem with a "library" of tags to be scanned. I'll keep thinking ;)
RasPi
Thu, 2016-12-01 09:05
Permalink
I tried to launch the debug
I tried to launch the debug mode via mocp -D but there is only the file mocp_client_log generated. In this log I can only find, that the confirmation sound is played multiple times.
What did I do wrong that the server_log is not generated?
tomaszg
Thu, 2016-12-01 09:08
Permalink
Probably the server was
Probably the server was already running without -D, so only client saw the new option.
RasPi
Fri, 2016-12-02 08:05
Permalink
You're right - I found the
You're right - I found the code where the server was already run without debug mode. So you really helped me, the explosion sound was somewhere in the raspbain system provided by a preinstalled game :-)
But now I'm struggling with my Python code, something isn't working as expected...
Have you already seen that:
http://www.forum-raspberrypi.de/Thread-projekt-jukebox4kids-jukebox-fuer-kinder
Maybe watching that you're not "afraid" of the library-problem any more :-)
tomaszg
Fri, 2016-12-02 11:37
Permalink
Nice realisation - I might
Nice realisation - I might try to do something like that for my kid. However I need also something for adults. When you have for example 500+ albums keeping RFID tags for them around is not the easiest solution. Maybe it would just be possible to run MOC on such LCD screen ;)
RasPi
Fri, 2016-12-02 19:43
Permalink
I'm also doing that for my
I'm also doing that for my kid - it's her Christmas present i'm just working on.
I made some updates to my python script ... but running in the next problem. I'm a little stressed because of the time going by ...
Had you ever such problem: calling mocp --next or --previous stops playback and does not navigate through the playlist. I also can't find a hind in the logs.
This used to work, but I manipualetd my script on a different place that might not affect this.
tomaszg
Fri, 2016-12-02 20:06
Permalink
I didn't notice such
I didn't notice such behaviour but I rarely use command line options. Maybe for some reason some files cause mocp server to hang? Only serious issue I had on OpenWRT was related to non-ascii characters - they are sometimes garbled or even cause MOC to crash. However I think it is caused by slimmed down version of libiconv shipped with openwrt.
RasPi
Tue, 2016-12-06 20:06
Permalink
Well, I experimented a lot
Well, I experimented a lot but I have no clue why it's not working. Sometimes the "next" statement works fine, sometimes it causes Moc to stop. Previous isn't working at all.
Pressing "Pause" only works fine if Moc Client is not opened in the console.. I think I'll check if another player works more reliable to me :(
tomaszg
Tue, 2016-12-06 20:22
Permalink
But do you see anything
But do you see anything suspicious in the log after issuing these commands? Does it work when you try it manually (outside of the script)?
RasPi
Wed, 2016-12-07 18:47
Permalink
Typing the commands in
Typing the commands in Command line everything works fine...but not inside the script. Today I really found the first time a crude statement in the server log:
Dec 7 19:39:58.082876: audio.c:377 go_to_another_file(): Playing next...
Dec 7 19:39:58.082896: audio.c:398 go_to_another_file(): End of the list
...
Dec 7 19:39:58.083521: alsa.c:580 alsa_close(): ALSA device closed
Dec 7 19:39:58.083545: audio.c:490 play_thread(): Exiting
Starting playback again works fine, so the player is still running.
Any idea?
RasPi
Wed, 2016-12-07 19:16
Permalink
That's the full log beginning
That's the full log beginning from the "next" statement:
tomaszg
Wed, 2016-12-07 19:40
Permalink
Can't find anything
Can't find anything suspicious here. Looks like MOC really reached the end of the playlist. Especially since the problem appears only with the Python script, I would guess that the problem is in the script itself.
It's quite hard to debug by remote ;) Maybe you could try logging all executed MOC commands to a file and see that nothing suspicious is getting started? If this script is not very tightly tied to RPi, maybe you could try to run it on normal machine? Or even post it here for other people to look at it? (BTW. pastebin is a good thing ;) ).
RasPi
Wed, 2016-12-07 20:03
Permalink
Well, it's just a python
Well, it's just a python script :)
Maybe you can find anything - seems like I'm blind in the meanwhile.
Script to start Moc on boot
Script to control mocp
tomaszg
Wed, 2016-12-07 22:46
Permalink
I didn't read it very
I didn't read it very carefully (I don't know Python) - however it was pointed out to me that your init script runs MOC as user "pi", while the other runs it as "root". They are separate MOC instances and that might mess things up a bit due to some unexpected interaction.
However I don't really follow how that would produce errors you described. Only root version of MOC gets controlled with the second script so, both playlist reading and next/prev commands are set to the same instance. Do those users share some directories, like ~/.moc? Moreover if you started pi-instance with -D, why it received "next" command? I'm a bit puzzled and it's getting too late here for me to focus right now ;)
RasPi
Mon, 2016-12-12 06:45
Permalink
I had some Copy-Paste errors
I had some Copy-Paste errors in my script - sorry for that :-(
My "original" script in the meanwhile is full of out-commented code - this is what I didn't want you to read.
I tried to run it with different "test data", this time a radio play of my daughter, and i figured out whats happening with Moc:
I start playback and press randomly previous / next on my remote. Mostly Moc steps to the next track or steps back to the previous one. But sometimes the player skips one or more tracks.
Controlling Moc with console this behavior doesn't appear.
So last thing could be the remote - maybe a button is pressed too long and the command is sent multiple times to the player. I inserted console prints: each button press causes one console print. So what do you think, is it really the remote?!
jcf
Tue, 2016-12-13 20:12
Permalink
Which MOC Release????
I can see several possibilities here, but before we can help you any further we really need to know which release of MOC you are using.
RasPi
Wed, 2016-12-14 21:20
Permalink
Moc Version
Hi,
sorry...do you need any other information?
jcf
Wed, 2016-12-14 22:11
Permalink
The Process of Elimination
Okay, so that eliminates the most likely cause of what you're seeing as it was already fixed in MOC 2.5.0.
But that release is quite old now and there have been many bugs fixed since then. Are you able to try the latest 2.5 version (released as 2.5.2), or even the most recent release (2.6-alpha3)?
I noted from the log you posted that the audio you are trying to play appears to be sub-second in duration. Is that what you are expecting?
Is it possible you're just not hearing that short an audio? (We know that the RPi has some problems with audio, but if you're hearing it when driving from the command line but not your script then that implies not... but does imply the problem lies in the script.)
RasPi
Thu, 2016-12-15 21:25
Permalink
So in the meanwhile my main
So in the meanwhile my main problem is that the options Next, Previous and Mute via Remote Control don't work as expected.
I'm not sure if that is really a problem of Lirc, my remote or my script because if I just give a print on console after pressing the remote I just receive one line for each button press. Otherwise, if I control Moc just via console commands Moc works fine... :-(
Sure, I'd like to update - but how?
sudo apt-get upgrade
tells me that Moc v.2.5.0 is already the latest version.tomaszg
Fri, 2016-12-16 04:00
Permalink
If your distribution doesn't
If your distribution doesn't provide newer Moc, all you can do is to try to compile it from the source.
jcf
Fri, 2016-12-16 10:03
Permalink
Alternatively...
... ask the MOC package maintainer for that repository to upgrade.
jcf
Sat, 2016-12-17 07:08
Permalink
One and Only One
From your code (and it's not clear if that posted may contain cut and paste errors), when a new QR code is scanned you clear the playlist, add the new audio then start it playing. At any one time, there is only one item in the playlist so 'next' and 'previous' will cause MOC to stop playing.
You may also want to consult the configuration file's
SyncPlaylist
option as different clients can maintain distinct playlists and it may be this which is confusing you when a console client is also active.As for play/pause, that may be a separate issue but let's tackle the next/previous one and the playlists first then see if it still exists.
jcf
Sun, 2016-12-18 20:03
Permalink
Multiplicity
Is it possible that you have multiple instances of your script running? If there were two (or more) instances listening for and actioning the same interface signals then it would account for several of your observations.
An even number of instances each toggling pause would cancel each other out. If there were two instances each actioning a 'next', then the server would skip one playlist entry (although it's not clear how you would actually get multiple playlist entries in the first place, unless there's something you're not telling us about what the QR code represents).
tliero
Fri, 2016-12-30 06:25
Permalink
Use PulseAudio instead?
Hey there,
are you sure that this is a sound file that's being played and not just the infamous crackling noise on the RasPi?
I've built a similar player - which you might be aware of, since some of that code looks quite familiar ;) - and ran into similar problems. (Wrote about audio problems with moc and the RasPi here in German.)
I've solved them by using PusleAudio. Unfortunately, you will either have to recompile mocp to support that sound system or use the PulseAudio wrapper (which is an easier but less elegant solution).
In order to run with PulseAudio, the OSS sound driver has to be set as first option in ~/.moc/config. The mocp server is then started over the padsp wrapper with
padsp mocp --server
Anyway, I'm currently building my second player and can recommend the PHAT DAC extension from Pimoroni. This removes the headaches with all of the audio and provides much better sound as the original RasPi. So if that is an option for you, I'd say go for it.
jcf
Thu, 2017-02-02 00:59
Permalink
CLOSED
Despite our attempts to help him, the OP has disengaged without explanation.
I'm pretty sure this is not a MOC problem, but I guess we'll never know.